Data handling between VIs for idiots

[Ben]

Kevin posted

"

One possible advantage of a Notifier to a functional global is the ability to wait for a new updated value.  This can be very handy, depending on the app.

"

Now if the AE fired off a Notifier when it executed....

Thanks for that reply Kevin! It helped out with a design I am developing.

Ben

[MancPablo]

Thanks for all the replies, a few things to search for in the help menus.

Kevin, you're right with your interpretation: the diagnostics are logged at 1 Hz for QA and any post poscessing and the main program uses only a small amount of it semi-randomly to generate the final producted.

And I thought I was ok at LabVIEW programming! I guess there is more to it that reading in voltages and talking to serial ports!

Paul

[DFGray]

I must disagree with a previous post.  Queues are a great way to send information to multiple places, but only if you use the single-element version and treat them as a reference object.  Otherwise, they are point-to-point (or many points to one point).  In most cases, I prefer single-element queues over action engines/LabVIEW 2 globals due to their greater extensibility and better in-place performance.  They also are more compatible with my preferred programming style (an accessor for each item in a reference object rather than a single object - action engine - to handle everything).  They are easily embedded in LabVOOP objects to give you inheritance.

Last year, I gave an NI-Week presentation on the various reference objects available in LabVIEW and their pluses and minuses.  You can find a copy of it here - includes examples.  The executive summary is simple - use single-element queues or LabVIEW 2 globals for most things; use globals for look-up tables.

[Pnt]

I have noticed that queues have a large performance hit, when you use the name to call an existing queue, instead of a wire.

This is the main reason i don't use them. Although i have not tried calling it by reference.....

[DFGray]

Acquiring a queue reference by name will give you a performance hit, although the option is nice to have.  I always use them with a cached reference.  There are several options for caching this reference:

1. Use a global.  Globals are great for static look-up tables and this is a perfect use.  Watch out for name collisions between different toolkits.
2. Use a master queue to hold queue references to all your other queues.  This is what I usually do.  This results in never having to pass more than one queue reference into any subVI, so deep stacks of subVIs become manageable without huge numbers of inputs.
3. Use a LV2 global.  This is probably the best solution, since it is as fast as the global, and does not require a connection on the front panel.  It is extensible, but once you get ten or so objects, it gets a bit unwieldy to maintain.
   

[Pnt]

DFGray wrote:

Use a master queue to hold queue references to all your other queues. 

Nice trick ! Had never thought of it.

[Bob_Y.]

Damien,

Has this all been documented on NI's website somewhere other than just finding parts of it here and there in the discussion forums?  I think that this would be a good topic for a white paper or even a web seminar but should at least be a topic for a knowledge base article.

If one exists, could someone please post a link in this thread?

Thanks,
Bob Young

[MancPablo]

It seems to me like this topic has generated some interest and several options, I am ploughing through them at the moment. The stuff that DF Gray linked to has been very useful.

The problem for a lowly programmer such as me has been moving away from global variables and wires to transfer data. If I use the same subVIs and instrument in a slight different configuration, traditionally I have saved a new application development in a different VI library to allow them to be transferred to other machines. Problems start to arise when these different applications are opened simultaneously and you have two global variables open with the same name in different locations. Only one can exist in memory.

The dangers of being self taught. I also have to make it idiot proof so none labVIEW people do not fall into the same trap when simply running code.

Paul


Message Edited by Manc Pablo on 07-30-2008 09:55 AM

[DFGray]

Manc Pablo, given that you copy code and reuse it (good for you!), you should probably use the single-element queue approach.  Unless you specifically name your queues, copying code and reusing it will always result in unique data objects for each application.  This is also very useful for multiple instances of the same application (but that is another topic).  Both globals and action engines can get you into trouble with name collisions.  A rename solves the issue in both cases, but it can be painful for a large application and the issue of what to rename to is always there.  It also does not solve the multiple instance issue.

Note that some of the rename issue can be avoided by putting things in libraries and LabVOOP objects.  You then only have to rename the library or object, not every VI in it.  You will still need to relink after the rename, though.

Bob, I don't think this topic has been well documented by NI (one of the reasons I gave the presentation).  I will see what I can do about that, since I wrote a paper for the presentation...

[Kevin_Price]

DFGray,

I'm interested in your recommendation for single-element queues, and would like to know some of the practical implementation details. 

1. Do you create the queue with size=1 originally?  If so, does this allow LabVIEW to do some further optimizations?

2. How are "writes" handled exactly?  I first picture doing a Deque (and discard) followed by an Enqueue of new data.  Is this guaranteed to act "atomically"?

3. How do you choose reasonable timeout values where multiple processes may attempt simultaneous access to the single-element queue?  Do you use infinite timeouts (-1)?  Or do you use short timeouts and loop around your access attempts?  Or some other scheme?

4. Suppose a process succeeds at Dequeue but fails to re-Enqueue leaving the queue empty.  How do other processes handle that?  Their Dequeues will keep timing out, right?

5. What about error handling?  What are the scenarios where you need to add some smarts to the error handling?  It seems to me that the possibility of scenario #4 above may dictate that one may sometimes need to perform an Enqueue even if the Dequeue produced an error.

6. When are they significantly more optimal than Notifiers?   In the presentation, I see a Dequeue with data forked off to some processing code and also back to Enqueue.  It seems that a data copy would be possible, maybe even likely for such a scenario.  On the one hand, you want to re-Enqueue immediately to make the operation "atomic", but on the other hand this increases the likelihood that LabVIEW will need to make a copy of the data for processing.  Right? 

-Kevin P.,  intrigued and curious