06-18-2014 07:36 AM
@CMW.. wrote:
Hey,
If you use two event loops they will "compete" with each other for events what leads to an unpredictable behavior of your program.
This is not true. Each event structure has its own event queue. Any structure that is registered for that event will see it.
Regardless, I still recommend using queue to send commands to your second loop. There are some other weird things with having multiple event structures in a VI. Follow the Producer/Consumer setup. So your event structure will get the start button pressed and send via the queue a command to start the acquisition. When the stop button is pressed, the event structure will see that event and send the command to your aquisition loop to stop.
06-18-2014 07:50 AM
Mea culpa....
I thought it would be like this..
So one question remains,
what happens if you have one button control and register the same event e.g. value change in two event structures.
Will it be a problem?
CMW...
06-18-2014 07:56 AM
There is a lot of false information floating around regarding multiple event structures in one diagram.
As always, the real answer requires proper understanding of what is going on. It is prefectly feasible to have two (or more) event loops running int he same diagram if you know what you're doing. I use User events and multiple event structures regularly in my code.
Using one event structure to fire a control to trigger a second is certainly not a good way of going about things. As such I would assume (in the absence of other information) that you do not fall into the category of knowing what you are doing regarding multiple event structures. So my advice is:
Go the queue route suggested elsewhere.
Shane.
06-18-2014 08:01 AM
@CMW.. wrote:
Mea culpa....
I thought it would be like this..
So one question remains,
what happens if you have one button control and register the same event e.g. value change in two event structures.
Will it be a problem?
CMW...
Both event structures will receive the event. However, if you have certain options enabled and one of the event structures isn't being accessed, you could lock your front panel.
I would recommend giving the LabVIEW Help a look for Event Structures, caveats. And follow the links. There is some good information in there.
06-18-2014 08:03 AM
Thanks for making it clear.
I am using now one event-structure + a second while-loop (see attachment).
If using a queue then the Start is clear but when then the event fires a stop into the queue then the stop is not executed until the start is finished.
I am doing this now with global variables.
event Start = Set global to "STARTED" and the lower vi will begin execute
event Stop = Set global to "STOPPED" and the still running vi will check the global and execute a "stop vi" to return
06-18-2014 08:10 AM
Getting back to the original question, your best bet is a single event structure in one while loop, and a queue driven state machine in another while loop to drive your data acquisition (as has been said above). The event structure sends commands to the state machine using queues. No globals required (or wanted). No polling needed to determine state for the data acquisition. This will give you a clean, scalable architecture. These forums and the LabVIEW help provide many examples of this type of architecture. If you need more help. please ask.
06-18-2014 08:15 AM
I agree 100% with DFGray,
do NOT use globals for this. Use a Queue.
Shane.
06-18-2014 08:21 AM
I really would use a queue but the problem is that i then cannot stop the running vi.
1. I press "Start" in the event -> queue is starting my Measurement-vi which is running for some minutes
2. I press "Stop" in the event -> queue is queuing this command and waiting for start is finished before processing stop.
So with queue i cannot stop the vi, thats why i use globals.
06-18-2014 08:27 AM - edited 06-18-2014 08:27 AM
@OnlyOne wrote:
I really would use a queue but the problem is that i then cannot stop the running vi.
1. I press "Start" in the event -> queue is starting my Measurement-vi which is running for some minutes
2. I press "Stop" in the event -> queue is queuing this command and waiting for start is finished before processing stop.
So with queue i cannot stop the vi, thats why i use globals.
Your acquisition should be in a loop on its own, right? Just expand it to include the reading of the queue so that you can abort when you get the stop command.
06-18-2014 08:59 AM
@OnlyOne wrote:
I really would use a queue but the problem is that i then cannot stop the running vi.
1. I press "Start" in the event -> queue is starting my Measurement-vi which is running for some minutes
2. I press "Stop" in the event -> queue is queuing this command and waiting for start is finished before processing stop.
So with queue i cannot stop the vi, thats why i use globals.
Please look at P@Anand's post on the previous page. it contains links to the information on how to set things up correctly. The example shows you how to gracefully exit.