12-21-2012 04:19 AM
Hi,
I am building a EEg EMG data acquisition / displaying VI and i want to have an initializer loop that controls the the display and recording loop. I've attached the project file with it's Vi's.
When i press start, the initializer loop should start the display loop (that works) then when i push record, the initializer loop should also start the recording loop (that also works). but when i press stop, both the display loop and the recording loop should stop, sometimes they do and sometimes only one stops, i know the cause is that the remote button goes into false again in between loop cycles and lets the recording loop keep on going. I know there should be a better way to handle this with occurances but i can't figure out how...
Best regards,
Thijs
Solved! Go to Solution.
12-21-2012 10:09 AM
Your code is kind of a mess and you should probably take some time to go through the online tutorials. It is a wonder this works at all. In particular you should look at examples for state machines and the producer/consumer design pattern.
One, get rid of all the sequence structures especially the stacked sequence structures. Learn how to use dataflow to control the order of operation.
Two, using multiple event structures within a single VI can be problematic at times.
Three, It is never a good idea to place code that takes a fair amount of time to execute inside an event structure. You have very long while loops inside of your event structure.
Four, learn how to use queues or notifiers to pass data between loops. Variables, global or local, can lead to all kinds of race conditions if you are not comfortable. Race conditions are also very hard to debug. Queues and notifiers will elminate these types of issues.
Occurances are not what you want to use to stop multiple loops. Queues or notifiers are the preferred methods. In your case I would use a notifier. When you lool at the examples for state machines and the producer/consumer design pattern you will see how you can use a queue or a notifier to signal a stop condition.
BTW, you do know that all of your loops are infinite loops since you wired a constant to them, right? Are you using the Abort button to stop your application? If so don't. The abort button is there as an emerency stop. It's like stopping your car by running into a wall.
12-21-2012 10:18 AM
12-21-2012 10:23 AM
@ThijsBoeree wrote:
Hi,
I knew my loops are infinite because this is setup version, and i wanted to test things. Thanks for all the advice. One question, why is there a problem when putting long loops in an event structure? I was going to pass data through queue's... I just wanted to use the global variable for references, they never change and they are accesible everywhere...
Well i am going to check some tutorials about notifiers!
Best regrads,
Thijs
Whether this is just atest VI or some throw away code you should never write loops that are infinite. The only way to stop your code is a hard abort. That is never a good things.
Event structures are generally used to control the UI. If you have a code inside of it that takes a long time to execute than you will not service any other event in that event structure until the code completes. If the user is presing a button on the VI and nothing happens they will probably press it several more times. Now you have queued multiple events that will need to be serviced. Your code becomes unresponsive to the user and that is very annoying.
12-21-2012 01:27 PM
@ThijsBoeree wrote:
Hi,
I knew my loops are infinite because this is setup version, and i wanted to test things. Thanks for all the advice. One question, why is there a problem when putting long loops in an event structure? I was going to pass data through queue's... I just wanted to use the global variable for references, they never change and they are accesible everywhere...
Well i am going to check some tutorials about notifiers!
Best regrads,
Thijs
Just put a 2 sec wait in an event and you'll see why. 🙂 Just like any loop the next iteration cant activate until the previous is finished, and in case of event it'll get very sluggish. When so you need to leave the pure event structure? Well, that depends on your needs, but i'd say once an event takes more than 0,1s.
/Y
12-21-2012 03:23 PM
12-21-2012 03:25 PM
Look at the producer/consumer design pattern. It does just what you ask.
12-21-2012 06:06 PM
HI,
I just took a look at the code. The reasons for one loop aborting while the other running is
1. 2 event structures run in parallel with same event configured in both events. So, when one loop captures the event, the event gets deleted and the other loop still doesnt recognize the event. I doubt this should have happened as always.
But as people told code basic optimization should be followed :).
Have 3 direct event structures in a block diagram is a sin in LabVIEW basics.
All the best.
12-21-2012 08:47 PM
Muthuraman wrote:HI,
I just took a look at the code. The reasons for one loop aborting while the other running is
1. 2 event structures run in parallel with same event configured in both events. So, when one loop captures the event, the event gets deleted and the other loop still doesnt recognize the event. I doubt this should have happened as always.
But as people told code basic optimization should be followed :).
Have 3 direct event structures in a block diagram is a sin in LabVIEW basics.
All the best.
Not true. Each event structure registered for these static front panel events maintains its only queue of eventss. If each event structure is registered for the same event, each will capture that event. Second, the two event structures in the OP's code are not registered for the same event. One is registered for "Remote Start" and the other for "Remote record".
Multiple event structures is not "a sin in LabVIEW basics." But they can cause problems for new users if they aren't carefule (just like local variables and race conditions) if they aren't used properly.
12-24-2012 02:34 AM
Nice, concise description!