Multiple Dequeue Element VIs in loop

[Greg McKaskle]

Correctly diagnosed.

As originally written, but not what was posted, the code was told to wait for all six queues to have something posted to them before running the next loop iteration and processing the second command in any of the queues. That would in fact be a pretty odd requirement for a state machine, but that was what was written.

Using the timeout to avoid the blocking of the dequeues will allow the original code to work, but it also makes it effectively a polled loop. Technically, the loop will run sooner if all queues have something in them, but if nothing is posted, the loop would run every 1ms. Probably not a big performance issue, but that would depend on what you expect.

Depending on what is being enqueued and how they are processed, there are two pretty common patterns.
1. Go with a loop per queue. Don't be afraid to put the loop into a subVI which may allow you to reuse code depending on the processing, and will make the code much more readable. Because LV execution is not stack based, the engine can efficiently sleep very large numbers of parallel code clumps such as the loops, and they will awaken and be scheduled with very little overhead.
2. If you are wanting to process the results more centrally because of combined effects, consider posting to a single queue, but put an array into the queue data and combine up to your six data items into the array.

Greg McKaskle

[Lisa Perez]

Dave and Greg: Thank you for your suggestions! Looks like I've got the original program up and running now (although I will indeed be keeping the multiple state-machines as set up in my revised program as you both have suggested).