LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous Call - collect values without waiting for sub VI to finish executing

Hi All, I'm relatively new to LabVIEW and for the first time I'm attempting to make use of Asynchronous calls in a program.

 

What I would like to accomplish, generally, is this: At the beginning of the main vi, begin running a sub-vi in the background. This sub-vi is collecting streaming data from an instrument with a refresh rate of 50Hz. At various points in the main vi I would like to call the instantaneous value of that streaming data from the sub vi, passing it back into the main vi, while allowing the sub-vi (the streaming data collection) to continue running. The reason for this, is that I need to collect the data from this instrument many times wihtin a loop, and the connection initialization to the streamin data instrument is both slow and faulty, and takes too long if I have to initialize the connection, collect the data, close the connection, each time I wish to collect the data. I would prefer to initialize the connection once at the beginning, have a stream of continuous data being collected in the background, and then at certain points within the main vi loop, query that streaming data for its instantaneous value, but allow the streaming data sub vi to continue running.

 

I recognize that a method to allow the streaming data collection sub vi to run in the background is to use the Asynchronous call method - however, to collect the data I need to use an asynchronous wait, which will only collect the data if the streaming data sub vi finishes executing. How can I collect the data at a particular instant while still allowing the subvi to keep running (thereby minimizing the number of times the connection to the instrument needs to initialized)?

 

Any suggestions or alternative methods would be great!

 

Thanks

 

Jason

0 Kudos
Message 1 of 8
(3,988 Views)

This is typically solved in a different way than what you envision. Have your parallel deamon post its current values to a buffer. This could be a global variable (gasp!!) or an intelligent global variable (a VI with loop that executes always once and has an unitialized shift register that can either be initized or read based on a control input). You can add extra code to the read and write selection such as scaling etc to turn the intelligent global into an action engine that does extra things on its different methods.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 8
(3,984 Views)

Hi Rolf,

 

Thanks for the response and the sample VI, really appreciate it.

 

I can sort of envision how this works, but I'm still a bit confused. How can I run this in parallel to the rest of my program without using Async call?

 

Is the idea here to wrap this intelligent global around the rest of my program? Any way I try to envision it I run into the same issue - that I cannot continue on to the rest of the program until the streaming data sub vi stops. Where in this scheme (chronologically and location-wise within the vi) do the streaming VI and the main VI go?

 

I'm still pretty new to labVIEW, so if you spell out the chronological steps for me that would be awesome.

 

Thanks again for your help!

 

Jason 

0 Kudos
Message 3 of 8
(3,959 Views)

Here is a quick and dirty example. Don't take it verbatim, it is not really a good sample of architecture but it shows two intelligent global variable uses, one for the data, and another one for the shutdown event. Typically you would extend the shutdown event to be really a command, so that your GUI loop can send commands to the deamon loop to perform certain actions beyond the command to shutdown itself.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 8
(3,939 Views)

If I may suggest, if the application needs are modest, you can also do this with a notifier.  Create it in the "main", pass its refnum along to the data-gathering VI, which can post notifications as frequently as it generates data.  The "main" can Wait on Notification whenever convenient to retrieve the freshest value.  The mechanism for the "main" to command the "data-acquisition" to stop can be as simple as destruction of the notifier, which causes the next post operation to fail (returning an unambiguous error code).

 

Just an alternative.

 

Best regards,

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 5 of 8
(3,933 Views)

I "second" the idea of using a notifier to retrieve "the latest value".  I've been doing LabVIEW development for several years, and didn't "get" the value of notifiers (why have such a thing?) until about a year ago, when I had a need for something exactly like you are proposing ...  Note that if the detached (asynchronous) routine is continually sending its latest streamed value to the Notifier, when the Host routine does a "Wait on Notification" to get the latest value, it shouldn't have to wait at all since the detached routine will have put many "ignored" values on the Notifier.  Think of it as a lossy queue of length 1 ...

 

BS

0 Kudos
Message 6 of 8
(3,899 Views)

Even better, the Wait On Notification primitive has a boolean input which governs whether it returns immediately with the currently available notification data, or hangs around (up till timeout) waiting for somebody to post something guaranteed fresh.

 

That's hardly NI's description, it's mine, and mine is a lot more colloquial.  I kinda like it, now that I've written it.

 

Dave

 

 

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 7 of 8
(3,881 Views)

Thank you for all you feedback - I really appreciate it. I'll give some of the ideas here a try later on this week and let you know how it goes.

 

Thanks again,

 

Jason

0 Kudos
Message 8 of 8
(3,815 Views)