Data handling between VIs for idiots

[MancPablo]

Afternoon all,

I am trying to find the most efficient way to pass data between VIs. I have a program monitoring an instrument and doing some processing of the data. In the background I have a VI logging diagnostics at 1Hz. Some of that data is averaged up from 10Hz data, but the displayed and logged are 1Hz. This diagnostics VI is crudely constructed with a massive While loop and wait functions.

The main program needs the 1 Hz data at different points in its execution, certainly not every second. As I cannot pass data out of a While loop without stopping it, I am using global variables. I am self taught with Labview, and those around me who code in other languages frown upon the use of globals and I am trying to update my code and avoid if possible.

Is there any way of efficiently transferring data from a While loop (or a timing structure if I get brave) other than globals?

Paul

[F._Schubert]

You should use a queue. Search for Producer/Consumer Design Pattern.

Felix

[Pnt]

Another option is a functional global.

How big is your data?

[Graziano]

Hi!
   I suggest to begin with simple global variable, then you'll likely pass to Functional Global, which is a better option, but first just do some practice with globals.  They're quite straightforward to use.

graziano

[MancPablo]

I am happy using globals, been programming for years (albeit basic stuff). They have caused me trouble when I've copied programs from one machine to another and I've used them to store calibration factors or when two programs have the same global variable.

It is the method I've always used, I am being urged to move away from them.

As for size, I reckon I will be generating an array of about 40 elements to save and display at 1 Hz for the diagnostics. The instrument runs from a few hours to several weeks. Some of the elements I will need to average, others I will just need the current value.

Paul

p.s. functional globals, time to search the help menu!


Message Edited by piw1uk on 07-28-2008 09:45 AM

[Graziano]

Hi!
   they're not a built-in LV feature, you can build a functional global by hand... they're not strictly a LV component... look here!

graziano

[Ben]

"p.s. functional globals, time to search the help menu!"

Hi Paul,

I wrote this Nugget on Action Engines just for this type of question.

I hope that helps,

Ben

[Mythilt]

A small warning about using Action Engines, globals and queues for passing of data between two seperately running VI's.  If you use the programs as applications (ie, compiled into stand alone .exe's) they won't pass the information if they are compiled as two seperate .exe's.  This is because AE's, Globals, and Queues are limited in scope to their parent Instance.  While you are using the Development environment, even though the VI's are running seperately, they are sharing the same parent Instance (The LabVIEW developers environment.) but when you compile them into stand alone .exe's, they each will launch with thier own seperate parent instance (2 seperate RunTime environments) and thus won't pass between each other.

[Ben]

Jon posted

A small warning about using Action Engines, globals and queues for passing of data between two seperately running VI's.  If you use the programs as applications (ie, compiled into stand alone .exe's) they won't pass the information if they are compiled as two seperate .exe's.  This is because AE's, Globals, and Queues are limited in scope to their parent Instance.  While you are using the Development environment, even though the VI's are running seperately, they are sharing the same parent Instance (The LabVIEW developers environment.) but when you compile them into stand alone .exe's, they each will launch with thier own seperate parent instance (2 seperate RunTime environments) and thus won't pass between each other.

For the most part I have to agree BUT...

In the case of the AE's it IS possible to opene an explicit reference to the AE in the application instance in which the AE is running and use VI Server call by refeernce nodes to use the AE. This technique can also be used between application instaces running on seperate machines.

Unless you are developing a plug-in architecture, I'd try to keep the app in one exe and make my life simpler.

Ben

Message Edited by Ben on 07-28-2008 12:35 PM

[Kevin_Price]

Functional Globals and/or Action Engines are good choices that have already been mentioned.

Queues were also mentioned, but as I understand your request, I don't think they'd be the best choice.  It sounds like your "main program" will only occasionally need to consume a value, and I'm guessing that it'll want the most recent value.  If so then Notifiers, which are programmed very similarly to Queues, would be a better choice.

An example of the kind of architecture I sometimes make: my data acq code pushes its data into a queue.  I have a central data manager that pulls from this queue, perhaps does some processing and organizing of the data, and then pushes the results out into 1 or more queues and 1 notifier.  Any file writing code will pull from a queue to be sure that data is stored losslessly.  User display code and process monitoring code will often pull from the same notifier because they really only want on-demand recent updates.

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.

-Kevin P.