05-07-2009 03:51 AM
I've noticed several people talking about producer - consumer loops, but do not really know what these are. They don't appear in my help section, and i'm wondering if they're possible in LabVIEW 6.1
Could someone please explain what the principle is, and possibly even include a demo (with functions avaliable to me in my LV version). Cheers. 🙂
05-07-2009 04:03 AM
Hi James,
it's also possible in LabVIEW 6.1. You have to loops, one which produces the data and one which reads it. Use a queue for the transfer between both loops. That's it.
Mike
05-07-2009 04:12 AM
James,
Take a look at this link for Design Patterns
I remember using this as a reference when I was learning LabVIEW. It talks about producer-consumer in the presentation and has examples to match. It was pretty old when I first used it so I think it should be compatible with 6.1.
Hope this helps
David
05-07-2009 04:12 AM - edited 05-07-2009 04:13 AM
Just following a theoretical thought train.....
can you have multiple producer loops and multiple consumer loops? Would you also then be able to specify which queue each piece of data from the producer loops went to, and which queue the consumer loops fed off? Would they have to be the same (loops reading and writing to one queue each, or multiple queues)?
I assume you'd have to use local variables to transfer queues from one loop to another?
would the consumer loops have to operate faster than the producer loops(s) to stop the queue getting too big?
how could I synchronise consumer loops so that, though they may all take different times to execute, they'd all start their next iteration at the same time?
could event structures be used in place of some or all consumer or producer loops to minimize processor use?
sorry about the large influx of questions - I just like to know what I'm doing before I end up writing masses of code which doesn't execute properly!
P.S. Cheers for the link, David. 🙂
05-07-2009 06:01 AM
That presentation's proved extremely useful (am still going through it all) but my theoretical thought train questions still remain largely unanswered. Any ideas?
Also, why and when are control references used and what are their advantages/disadvantages?
05-07-2009 06:27 AM
I'm just experimenting with them now to get a better idea of how they work. I've attached a piece of code i'm using (the cancel button is off the screen). I don't seem to be getting wuite the output i'm sxpecting. My consumer loop has fewer iterations per unit of time, so that i can observe the queue increasing in size. However, i don't observe any of the elements i type into the control appearing at the indicator as they're read out of the queue. What am i doing wrong here?
05-07-2009 07:58 AM
Sorry James, I am at work just now so I don't have a lot of time, if any , to contribute during the day so there may be long delays before responding.
Lets just say that your top loop is "talking" 10 times faster than the bottom loop that is "lIstening" to the messages being sent. Thats is why the queue is growing and will take ten seconds to appear in your consumer loop. Try swapping the timing and see what happens. Whats the sub-vi with the triangle and ? mark?
David
05-07-2009 08:21 AM
That time difference was intentional - in theory (as far as i can tell) it would be possible for me to add elements to the queue quicker than they were read off, so the queue size would increase. I'd then be able to stop adding elements and watch as they gradually popped out the other end! When this wasn't working, i tried removing all time delays.
I've just figured out what was going wrong - idea came from your comment - and i feel rather silly now! Anyway, I've made a slight modification wherein I have to press the Pause button to give me 5 seconds of queue stacking time. 🙂
As for the little sub-vi, it's an OpenG VI. I've attached a snapshot of its help description. I use it loads now - very useful!
05-07-2009 08:28 AM
James you are getting dangerous!
I usually develop my consumer loops to be waitng on elements in a queue and use the timeout to check for other house-keeping tasks (like shutdown etc). If you check the number of elelments waiting in the queue you can process the whole batch at once and them go back to sleep.
Re: "How deep does the rabit hhole go" (complexities of queues and their count)
I have delivered apps that have used more than 400 queues to beable to dynamically link realted code modules.
Have fun!
Ben
05-07-2009 08:34 AM
James,
To answer some of your questions:
1. You can have multiple producer and consumer loops. I have used a three loop system several times (starting in the LV 3 days). I use (at most) a pair of queues for each pair of loops which must communicate with each other. If you have many loops, this will be come awkward, but likely not all loops would need to communicate with every other loop. If the loops are GUI, DAQ, and Process, the queues would typically be GUI Command (GUI -> Process), DAQ Command (Process -> DAQ), DAQ Response (DAQ -> Process), and Process Response (Process -> GUI). Note that DAQ and GUI do not communicate directly with each other in this scenario.
2. No local variables required. Send everything via the queues. The queue references are created in the top level program outside any loops and wired to the loops which use them.
3. The consumer loops can operate at any speed you like. The real requirement is that they consume that data being sent by the producer. Consider the DAQ loop above. Suppose it is acquiring and enqueuing one data point each millisecond. The process loop could run ten times per second and keep up, provided that it dequeued about 100 data points each time it ran. Lots of ways of doing things. Just make sure that all the data going each way gets dequeued.
4. Event structures are excellent ways of handling user input in the GUI loop.
5. I am not sure why you need to synchronize your consumer loops. You could use notifiers. But I suspect that a single consumer which could handle inputs at different rates from multiple producers might be better. What are you trying to do with this?
Lynn