Multiple Dequeue Element VIs in loop

[Dave Scheck]

Sorry for misinterpreting your question. Hopefully third time's the charm.

I changed my example to have a two loops instead of three like you're saying. In the "state machine" loop, I put two dequeue statements in parallel that update their corresponding outputs.

What I found was that when the iteration of the loop starts, both dequeue blocks are sitting waiting for data. When one queue gets its data, the second queue is still blocking. Unless that second queue data gets data, the first queue will never be dequeued again. This is because the loop iteration can't complete since everything inside the loop hasn't completed.

I was able to get this to work by doing the following
- On the timeout terminal of the dequeue block, add a constant of 1 (dequeue tries to get data for 1ms then gives up)
- Send the timed out terminal into a case structure. In the false case, put your processing of the data from the queue

What this will do is give each queue a chance (1ms) to process each loop of the iteration. If there is data waiting for it, it will be processed. If not, it wastes the amount of ms in the timeout. Chances are with the way Labview works, they will all happen in parallel since they're not dependent on each other, which means you shouldn't be wasting too much time in the timeout cases.

I can post a picture if you need me to.

[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).