LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event-Loop and parallel while-loop or better two event-loops?


@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 11 of 26
(1,309 Views)

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

0 Kudos
Message 12 of 26
(1,305 Views)

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.

0 Kudos
Message 13 of 26
(1,300 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 26
(1,295 Views)

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

0 Kudos
Message 15 of 26
(1,292 Views)

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.

Message 16 of 26
(1,284 Views)

I agree 100% with DFGray,

 

do NOT use globals for this.  Use a Queue.

 

Shane.

0 Kudos
Message 17 of 26
(1,278 Views)

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.

0 Kudos
Message 18 of 26
(1,271 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 19 of 26
(1,267 Views)

@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. 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 20 of 26
(1,258 Views)