ShaunR

Yeah, I keep all mah named queue refs in mah global vars to make the programming more handier.

I don't use refs at all The main reason I use named queues is that it is part of the message "routing".

Again, this boils down to best practices. SubPanelling implies asynchronicity, which can lead to race conditions and missed messages.

This is why queues are (IMHO) preferable under these particular circumstances since you don't miss messages and race conditions are alleviated (although not necessarily eliminated depending on your macro view). With queues you also have asynchronicity but you can also guarantee the order which, for control, is highly desirable..

One notable example is the Shutdown event -- it's possible that a system can issue the shutdown command the moment after a command to begin SubPanelling has begun. (We would agree here it's a bad programming practice to "stream" events into an unhandled queue for too long; that would probably be an abuse of pre-registration.)

Or you could begin sub-paneling (not quite sure if I'm understanding what this is correctly), send the shutdown and the sub-panel would appear then disappear as each element was removed (or you could flush it on the off chance it hasn't been enacted yet). I just think for this particular scenario, queues have many advantages over events, not least that you don't "lose" messages just because someone isn't listening.

rather than a Queue, where the sender and receiver share the same reference - decouples processes and simplifies philosophical (and practical) issues like ownership and lifetime.

Named queues

But in a less confrontational aspect. The issue I have is with the idea of "stuffing". That you create a registration, maintain it and generate events, whilst not consuming. At least with a queue you can monitor the elements and even restrict the size (for the scenarios where you want to "stuff")..

... just wait until the next evolution where you use User Events for both control and response!

Been there, done that; thrown it in the bin

Sure! Consider a simple DAQ loop, generating data. Consider one of many types of listeners (consumers)... a logger, a UI, a server that re-broadcasts the event over a network. The DAQ loop can run headlessly and independently of those subscribed to its messages, and they can come into and out of existence as they please.

So how is that any different from anything else (e.g.QE Messaging) except you can create memory leaks?

Just providing an example below to substantiate this vague statement.

<snip>

For these reasons (decoupling messenger from mailbox, the ablity to fire blanks, and one-to-many), I prefer User Events for interprocess messaging.

On the surface, it looks to me like an anti-pattern (maybe in the minority.....again....lol). The beauty of events is that you can fire them and they don't use resources unless there is something listening for them. That is one of their main advantages over queues This just seems to be trying to circumvent that feature to find a use (a singular use from what I can gather) and it doesn't really add anything to mitigate the drawbacks of events or, indeed, offer anything that cannot be achieved in other ways with more transparent foot-shooting opportunities.

Can you give a real-world example where you might use it?

You forgot the best of all, Chrome!

Indeed. In fact, there are very few browsers now that do not support them.

I've gone off Chrome at the moment though. Nothing to do with the features or the browser itself (which is arguably the best). More to do with it being so nosy and by default trying to track everything you do and put all your private info on their servers (as I found with my contacts list one day). Still. Not as bad as the iPhone.

Hey, if I'm wrong, I'm always willing to learn. The statement I referred to above just seemed not quite right, and I'm not sure at the moment of you guys agree with me or not.....

Well. Consider you have a public function called "Calculate". This function ,amongst others, uses a "Check For Divide By Zero" private function. You can craft a test case that that can be applied to the public function that specifically supplies a calculation that will result (at some point) in a divide by zero. You are using your knowledge of the internal workings of the "Calculate" function to indirectly test the "Check For Divide By Zero" private function. This is "Grey-Box" testing.

The major bonus to this approach is that your test case code can be generic (it only has to interface to the "Calculate" function) and just supply different calculations but test multiple paths through the private functions without having to create code for all-and-sundry. You can even do things like put thousands of your calculations in a file and just iterate through them, throwing them at the "Calculate" Function. The test code is not important, the tests data is what requires consideration and each piece of data can be crafted to test a path or target a specific private function within the public function.

Time is short, but I'm mostly referring to code coverage. If I test a public method, even though I may not see the private methods that the public one calls, those private execution paths are still under test. If I make a change to one of those private methods, change can still be measured through the public methods that use that private method. That difference could be faster execution time, different return values, changes in state, or even a null change-- seeing no difference is often a valid and useful metric...

As an aside. The examples that ship with the SQLite API are, in fact, the test harnesses and provide 99% coverage of the API (not SQLite itself, by the way. that has it's own tests that the authors do). That is why the examples increase when there are new features

1. Sony Bravia SmartTV - Websocket not supported

2. Samsung SmartTV - Websocket supported!!

3. Samsung Galaxy Tab - Websocket not supported

4. iphone - Websocket supported

Sweet!

Any Android smartphone/Tablet (Like your Galaxy Tab)you can use Firefox, Safari, Azura, Opera Mini, Opera Mobile etc They all work with Websockets (as long as it is over a network rather than 3G). There is limited support in the Ice Cream 4.0 native browser but before that (Gingerbread etc) .... nope. iPhone/iPad uses Safari so that's not a problem. I'd be interested to find out more about the Bravia (what OS/browser etc). Sometimes websockets are supported but need enabling as they are off by default (like Opera). I think the issue with TVs will be purely down to being able to install apps if the native browser doesn't support them.

So it looks like it's only the Sony Bravia that is the odd-one-out. I wonder also about the LG since most smart TV's have gone for either Linux or Android.

So it looks like it's only the Sony Bravia that is the odd-one-out.

Well. A bit more digging and it looks like the Bravia Smart TVs may be using Opera

BRAVIA TV, Opera

So it looks like that may be a go if you can enable it!

N:B: I was mistaken earlier. Opera Mini doesn't support them but Opera Mobile does).

Well. There is white-box, grey-box and black-box testing.

Testing the public interfaces is generally black-box (test the exposed functions without knowledge of the internal workings against a spec). Testing individual methods is generally white-box (full factorial testing with detailed understanding of the internal workings of the function). Testing public methods with specially considered test cases, crafted to exercise internal paths within the functions is grey-box (and also requires detailed knowledge of the internal workings).

Positive black-box (i.e. test for what it should do) and negative grey-box (i.e test for what it shouldn't do) together will always give you the best test-cases vs coverage than any amount of white-box testing.

If you want to write 3 times as much code to test as the original code and have a 95% confidence. Then black+white is the way forward. If you want to write a fraction of the original code in test cases and have a 90% confidence, then black+grey is the way (and you won't need to solve the problem ).

Another thing you can do is set the subsystems execution system to something like "Other1" then dynamically launch it. This will force it into a different thread pool and the LV scheduler should do the rest. It will also give you better control over how much slice time it can consume by setting the different priorities (this assumes your DLL supports multi-threading and doesn't require the dreaded orange node).

I'm not usually one for personal advice, but you might want to see a doctor about that.

Thanks Asbo. I just spat my coffee all over my keyboard

Actually. There are more like 5 in total. Saphirs is fully commercial, mine is free for non-commercial and the others are free but generally have limited features and support on the various platforms (LabVIEW x64 for example). But all that is really for another thread (even though it is YOUR thread....lol).

Good grief, why are there three?!

Because a fast, self contained database is a superb and robust solution to many of LabVIEWs applications.

It carries a noncommercial license. How do I get a commercial license? None of the work I do is noncommercial.

The commercial licencing is changing (check the site next week ). That won't stop you downloading and playing though.

As an aside, I would use my new favorite tool, SQLite (here, or here), to actually hold and serve up the data.

Yup. The SQLite API For LabVIEW comes with an example of decimating a waveform in real-time with zooming.

Hi Shaun,

I am definitely interested. Actually I'm trying to arrange to test this with one of the my client's distributor for Samsung SmartTV but have to wait until we are ready. If you have something ready, I could request for the test date to be earlier. So, do PM me

Thank a lot!

OK. Sent. Have fun and let me know how you get on.

By the way, websocket is a third-party toolkit that I need to buy, am I right? Is websocket the same as labsocket?

Websockets are the technology and yes, both the Labsocket and the Websocket API For LabVIEW are 3rd party tools (although not the same - labsocket requires a STOMP server, I believe. Whereas the API is direct TCPIP so no server required).

If you're interested, then I can PM you a link to the Websocket API live demo. You can then see if you can use it from a Sumsung Smart TV (because I would like to know too ).

Apparently the Samsung 2012 models use a Maple browser which is Webkit based (Webkit supports websockets). There is a very brief comment of surprise on Google Groups that websockets are working so it could well be an option.

I may not understand the architecture in question. As I understand it, if you have a subVI Front Panel in a subpanel of the main VI, then clicks on that (sub)Front Panel trigger events in the subVI’s event structure. And Alex is going to communicate this to the main VI via a queue, with the main VI talking back via a User Event. Should all work fine.

Yeah. I wasn't very clear in pointing out the caveats (and wasn't worded very well either-been up for 36 hrs already. I shouldn't really post).

using_events_and_subpanels

Which events don’t work in subpanels?

The event structure. Events are handled in the owning vi.

Websockets are definitely an option, as is building your VIs into RESTful web services using LV.

Websockets are only an option if the Samsung Browser supports them (or you can put a browser on there that does).

Can't think of any problems with what you have listed, but there are a couple that I can think of in terms of cons vs queues..

Cannot use them for subpanels (well, you can, but your events won't work).

Cannot guarantee execution order (might not be a consideration for you).

Cannot easily encapsulate (for the reason you mentioned about typdefs).

Hi Guys,

I'm about to start a SCADA-like project where I need to publish some of the results to a few Smart TVs connected to our cRIO via LAN. The current choice now is the ones made by Samsung. I did some research on how to show the results on the Smart TV and believe there are only two possible methods in doing this, which are either using the remote panel, or WebUI. After getting more detail requirements, I think I cannot use WebUI since the GUI provided for WebUI is a bit primitive - there are certain types of customized graph/chart that cannot be done in WebUI. Now, I am left only with remote panel. I've heard 'mix responses' on using remote panel for web-based access via PC and was told to expect a lot more issues and headache when trying to do this on a Smart TV.

Has anybody work or done something similar? or perhaps, can this be done in the first place?

Please advice. Thanks.

Shazlan

Websockets?

ShaunR:In your latest example, you have a case structure named "Destroy" on your "Queue.vi". In there you flush the queue and then destroy it. Is this normal when working with queues? Its just that majority of the examples I've seen with queues, they just seem to release the queue in the end.

Kas

Releasing a queue doesn't destroy a queue unless the reference count falls to zero, you wire true to the "Force Destroy" input or all VIs that have references to the queue go out of memory (too many bullets in the gun to shoot yourself in the foot with IMHO). The obtain only returns a reference to a queue, not the queue itself (which can cause memory leaks). This means you have to be very aware of how many "obtains" to "releases" there are in your code and, if you pass the queue ref around to other VIs, ensure that you don't release it too many times and make the reference invalid. Since the VI obtains a new reference and releases it on every call if there is already a reference (which makes it atomic and ensures there is always 1 and only one ref), you only need to get rid of the last reference once you are finished with the queue completely and don't have to worry about matching release to obtains (i.e. it protects you from the ref count inadvertently falling to zero, vis going out of memory and invalidating a queue reference or leakage). The flush is purely so that when you destroy the queue you can see what was left in the queue (if anything). The upside to this is that you can throw the queue VI in any VI without all the wires and only need to destroy it once when you are finished with it (or, as I have used it in the example, to clear the queue).

I've never thought comparing software products with hardware or physical products was particularly relevant.

Why is software so special? It is a tangible deliverable that can be measured and quantified. It's not as if it is like, say, a thought!

Retail software products are nothing like skyscrapers. Imagine if I said to an architect, "I want you to design me a new skyscraper I can build anywhere, but I don't know where I'm going to put it or what environmental conditions it will be subjected to." Would you expect the architect to be successful?

After consultation to refine the requirements. Yes.

If I built one copy of the skyscraper in Antartica and another copy in the Sahara, would they both function equally well, or would there be defects requiring changes to the design? What if I built one in an earthquake zone, or a tsunami zone, or on a raft in the ocean, or on the moon? The desktop environment in which retail software products exist is much less constrained than any architect has to worry about.

I cannot believe you just wrote that.

This is reductio ad absurdum argument. What is worse. Is that it is a reductio ad absurdum arguement based on an analogy

Let me ask you this though. How much retail software only runs on Windows, or only on Android, or only on Mac? How much retail software written by anyone actually runs on all available operating systems? (environments). You could probably count those that run on more than one on your fingers (LabVIEW being one of them).

Some companies may do public betas for that reason, but it's not universal in retail software and I really doubt any large software companies do it for that reason. (Except maybe Google with GMail and GoogleDocs) First of all, public beta testing isn't free. You need to hire beta coordinators to manage interactions with the beta testers, assemble feedback, nail down repro cases, distribute the information to the developers, build infrastructures for getting the software to customers, etc. True, beta testers typically do not get paid (though sometimes they get other forms of compensation,) but that very different than claiming beta testing exists to exploit a free resource.

Large software companies only do anything for one reason and that is to reduce costs and make profit. I would wager very few (if any) companies hire for special roles of public beta tester cordinator, it is usually just an extension of an existing employees role-managers are easy to come by and large companies are full of them. The same goes for IT. So of course they exploit a free resource. They'd be stupid (in business terms) not exploit someones offer to spend time and effort in testing for no free when they would have to spend considerable amount on employing a department to do it..

Second, in my experience, public beta testing usually results in relatively few new bugs being filed. There were typically at least some new bugs, but not nearly as many as you would expect. Public beta testing of retail boxed software is not a very effective or efficient way to find new bugs. If companies were just interested in saving money they would skip public beta testing altogether. Why do they do it? Depends on what kind of software it is. Sometimes game companies will release betas to test play balance. All the betas I've been part of like to get usability information from customers.

They also specifically use beta testing as a way to check how the software works in a wide range of pc configurations. (Equivalent to putting the skyscraper in the Sahara or on the moon.) There is no way any software company can gather the resources required to test their software on all possible pc configurations. When I was at MS Hardware they had a testing lab that contained (to the best of my recollection) ~50 common computers for software testing. Some were prebuilts from Dell or other vendors, others were home built using popular hardware components. Between all the different hardware combinations and the various driver versions for each piece of hardware we still knew we were only covering a very small slice of the possible configurations.

I don't subscribe to the "software is special and harder than quantum mechanics" school of thinking. I happen to think it is one of the easier disciplines with much less of the "discipline". If you are doing full factorial testing on different PCs then you a) don't have much confidence in your toolchains, b) don't have much confidence in your engineers and c) expecting to produce crap.