LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

event structures for dummies

After all the great help with data handling, I thought I would ask a question about event structures.

I have a main VI that sits around and lets me read in files and change variables. Once I am happy, I press start which fires up some sub VI that start running in the background. I have tried this using event structures. But then disaster strikes!! One of my variables is wrong and I need to stop/reset the sub VIs (without stopping the main program). However, my subVI is running in a timed loop continuously, within the event structure, so it's stuck. Attached is a very simplified VI of what I mean.

I basically want to run a program, set up some variables, set off a background subVI, update/reset if needs be and then press the big continue button to the next stage whilst the subVI is still chugging.

Any suggestions from the Guru's? I do not think event structures are the way forward
"When I read about the horrors of drinking, I gave up reading"
0 Kudos
Message 1 of 4
(2,748 Views)
From your description, I think event structures could be very useful, albeit you need a bit more experience and understanding in their implementation.

First, remember that it is a structure and, as such, still depends on data flow. While it will wait for a trigger before it executes, once code is executing in one of its cases, no other events may trigger until the current event finishes and (assuming a loop is involved) the next iteration starts. Although the next event will queue (so no events are lost), it will not execute until the current event ends.

That being said, try looking into a Producer / Consumer type architecture. Basically, you want to use the event structure to gather user input and send commands to the rest of the code. This way, you won't get locked into a single case.
-Cory
0 Kudos
Message 2 of 4
(2,741 Views)
The important thing about event structures is to use them in the right way. For example as a rule of thumb, don't put into an event handler anything that will take more than about 200 msec or so to complete. Why? Studies have shown that 200 msec is the longest delay you can generate without the user noticing the delay (obviously YMMV).

One good solution (as corys pointed out) is the Producer/Consumer Loop - but there are a variety of others. For example, I have created applications where pressing a button launched a long task as a separate process running in the background. When it finished it passed data back to the GUI using another event, queue or some other mechanism.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 3 of 4
(2,699 Views)
Cheers guys, I will have a play around. It seems from what you're saying and yesterdays efforts that having subVIs that have while/timed loops which are embedded in an event or producer/consumer loops isnt the way forward as the event or consumer loop will execute ad infinitum waiting for the loop to stop, which in my application they never will.

I think I will look at using queues to pass/update variables to my subVI as I believe I can change a queue entry anywhere within my program, if referenced properly.

Paul
"When I read about the horrors of drinking, I gave up reading"
0 Kudos
Message 4 of 4
(2,680 Views)