LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the fastest way to pass data between parallel threads?

I have a top level vi running with 6 parallel threads. I need to pass some data from digital I/O to several of the threads. What is the fastest responding way to do this. I am controlling a machine that has quite a few sensed events happening at very close intervals, some as close together as 1 to 2 milliseconds, and I seem to be randomly missing the signal from these sensors. How can I distribute the I/O to the different threads and not miss any inputs?
0 Kudos
Message 1 of 5
(3,655 Views)
I usually use a Queue to pass data from one loop to another. Other choices are Functional Globals or Notifiers. It kind of depends on what you need to do as to which one is best, so it's a bit hard to recommend one over the others without knowing more about your application.

Both Queues and the Functional Globals (if written correctly) can buffer data so you're less likely to lose data if one loop gets behind the others.

Ed


Ed Dickens - Certified LabVIEW Architect
Lockheed Martin Space
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 2 of 5
(3,645 Views)
I have used queues with great success in situations like the one you describe.  Queues provide some additional features like the ability to distribute the data over a network, and the naming of queues makes debugging and testing much easier.  I have never noticed a performance hit when passing data over a queue from a DAQ loop to an analysis thread (typical producer-consumer design pattern).
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 3 of 5
(3,631 Views)
Thanks for the replies. I will try it both ways, with the functional globals, and with queues. I had not considered the later. FYI, both local and global variables were FAR too slow. I was randomly losing limit switch closures. I realise that I may be asking a lot from the software, but it is a case similar to many I have encountered over the years. The hardware is less than adequate, and the customer expects me to compensate in software! Gonna have to "educate" this guy a bit. Thanks again Dave
0 Kudos
Message 4 of 5
(3,600 Views)

For the sake of completeness, there's one other option you might consider that's very similar to a queue in functionality and implementation, but has a slightly different slant: the notifier.

Notifiers allow for communication between multiple loops without the need for polling, just like queues. The difference is that notifiers don't have the inherint buffering capability that queues have. Only one data item can be stored in a notifier at a time, and if it gets overwritten before it's read by a consumer loop, then it's lost forever. It is possible, however, to send and wait on multiple notifications at a time.

Notifiers are optimal for applications involving one producer loop and multiple consumer loops, since multiple loops can read the data item without removing it, unlike the queue. The consumer loops don't have to poll, since they are "notified" that a new piece of data is ready for them to process.

Notifiers are located in the synchronization functions palette.

Jarrod S.
National Instruments
0 Kudos
Message 5 of 5
(3,564 Views)