01-14-2009 04:24 PM
Hi krispiekream:
Is there an error passed to the conditional terminal in the bottom loop that causes it to stop? If so, what is the error number on the line?
A. Person
Applications Engineer
National Instruments
01-14-2009 04:39 PM
01-15-2009 02:01 AM
I asume that you are seeing the consumer to wait for a queue element. That is not "stopping" but "event based waiting".
The advantage of "event based waiting" is that you will not create any CPU load unless an event occurs.
In general, you use a producer/consumer (event based) if you want to work on datasets where the analysis takes some time, but you still want to have your UI or other datasource accessable/working. So you have to split up analysis and data source into parallel "executions", so parallel loops.
From what you are writing in your last post, i am not sure if producer/consumer is the correct architecture for your task. So please describe what the task is and why you have the feeling that you need the consumer to work in a polling architecture which is absolutly not the idea of producer/consumer!
Norbert
01-15-2009 05:32 AM
In your code you had two bottom loops.
Which one stopped unexpectly, and more important how does your code look?
01-15-2009 06:36 AM
If i interpret the code and the description made on this forum correctly, the inner loop of the consumer is never entered except when an element is enqueued by the producer.
And to clear some things up in this thread:
A loop is never closed, it is either running or not running.
If a loop is running, it could wait on something (wait functions, functions which cause the loop to rest until something happens like dequeue).
If a loop is not running, it is either not entered yet or it is finished in its execution and therefore left.
Analyzing the code (Producer Consumer State Machine demo.vi) reveals the following: (please note that a and b run in parallel!)
The code is not executable since latching is not possible for buttons with local variables attached. You have to switch it to a switching behaviour.
Running the VI will
1) Create a queue for huge data elements.
2) Init the shiftregister at the consumer with "Initialize".
3) Enter both producer and consumer loop.
4a) The producer will wait for a value change event from either Queue Event or stop in the event structure.
4b) The consumer will wait (in the dequeue function) for any element to be enqueued in the queue.
4) Please note that both loops are waiting without generating CPU load. The highlight mode will not change unless a loop continues to work!
5) The whole VI will proceed working if either Queue Event or stop is pressed on the frontpanel. This change will create an event cought by the event structure within the producer.
6) The producer will insert a new queue element only if Queue Event button was pressed. If stop is pressed, please proceed at 10).
7a) After the element has been enqueued, the producer will proceed to its next iteration and wait for new interactions with Queue Event or stop.
7b) The consumer will immediatly dequeue the new element and proceed to the case structure. Since the case selector is connected to the shiftregister, it will enter case ""Initialize", Default". The execution will enter the inner loop and keep executing it until stop returns a TRUE.
😎 Pressing Queue Event again on the frontpanel will enqueue a new element in the queue. The producer will start a new iteration waiting on a value change of Queue Event or stop again. Since the consumer is still executing the inner loop, it won't dequeue the element.
9) Goto 😎 if pressing Queue Event again.
10a) Pressing stop will stop the producer. When the producer is finished, the queue will be destroyed.
10b) Pressing stop will return a TRUE in the (currently running) consumer if you are lucky when you chose "switch until released" (depending on the waiting time of the loop, with 10ms you will most often be lucky!). Not getting TRUE will proceed the loop until stop is pressed again. In that case, the button will be "pressed" graphically on the frontpanel permanently.
11) Considering the consumer will get TRUE at stop, it will finish the inner loop. The shiftregister will get a new value: Stop.
12) A new iteration will occur in the consumer. It will try to wait on the queue but the queue is destroyed. So the dequeue will return an error.
13) The consumer will execute the Stop case of the case structure. Since it is nearly empty, nothing notable will happen.
14) Because an error occurred in dequeue, the consumer will exit and the VI will be finished.
There is no need for highlighting anything if you stick to the dataflow rules defining LabVIEW:
A node will execute if all its inputs have valid values; a node will return valid outputs on all outputs simultanuously only if it has finished execution.
hope this shed some light on this question,
Norbert
01-15-2009 01:28 PM - edited 01-15-2009 01:32 PM
01-16-2009 02:21 AM
krispiekream,
sadly, the screenshot does not help much. It does not show what you want to do, it shows how you try to solve something. That is a huge difference.
Somehow, the situation reminds me of project management. I hope you are familiar with this cartoon.
Regarding your screenshot, the first sequence frame serves no purpose except creating overhead. The loops would run in parallel, but do not transfer any data/information between them. The bottom loop would additionally create 100% CPU load at a single core.
The comment on the right side is not understandable for me....except that i can tell you: a wire never looses its data!
hope this helps,
Norbert
01-16-2009 10:36 AM
02-17-2009 04:55 AM
Sorry for the delay in my reply, have overlooked your question....
Well, software developement would be too easy if there was only a single way to solve all issues. I recommend you to look into the variables and see if there is "packing" possible.
In general, variables can be easily replaced by shift registers, but this is, as always, not the solution for every request.
So maybe, using Functional Global Variables (aka Action Engine) or Notifier/Queues is the better choice.....
hope this helps,
Norbert