Discussion:
event structures for dummies
(too old to reply)
Manc Pablo
2008-08-07 14:10:08 UTC
Permalink
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


event structures for idiots.vi:
http://forums.ni.com/attachments/ni/170/347531/1/event structures for idiots.vi
corys
2008-08-07 14:40:05 UTC
Permalink
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.
mikeporter
2008-08-08 03:40:05 UTC
Permalink
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...
Manc Pablo
2008-08-08 08:40:07 UTC
Permalink
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
Continue reading on narkive:
Loading...