another nested events question

[BernieSAIC]

I have read the threads regarding this and still think I am able to get this working.  All I need is a simple calculation with a value change in a nested Event structure.  I know I can do it with a state machine and being crafty but would like to hear from others regarding getting this to work.  If not I will just go the other way.  I want to give this a shot though.

Thanks

LV2010 XP

[tbob]

Your VI hangs up.  I don't think it is a good idea to have nested event structures.  There is no reason to do this.  One event structure can handle any event, so why nest?  A well thought out state machine is not only much simpler to design, but also much simpler to debug and maintain.  Why do you want to complicate matters?

Also, use shift registers with error wires, wire them through each case (don't use "Default if unwired") or else you will lose any errors from one loop iteration to the next.  Why use a boolean checkbox to stop the VI when you can use a boolean stop button and an event case for it.  Don't compare the case string to "End" to stop the VI.  Just create an "End" case and wire a True constant to the stop sign.  This is one of the few cases where you should use "Default if unwired".  See attached VI.

[BernieSAIC]

Thanks tbob.  I will just go with the state machine.  I was just wanting to try something new.  As for the other things you mentioned,  I just threw this together as quickly as possible to get ideas.  My work vi has all of those implementations you mentioned.

[altenbach]

---

@tbob wrote:

I don't think it is a good idea to have nested event structures.

---

I would go a step further and say that event structures should never get nested and should never be in structures that can prevent them from reacting. Event cases should never contain interactive loops. There should never be more than one event structure anywhere in the same loop.

Looking at your code, you have a complete misunderstanding of event structures:

An event structure does NOT adhere to dataflow, meaning it will queue up an event even if dataflow prevents it from executing.

There is no event that reacts to the stop button, so the VI cannot be stopped unless another event is fired too.

Your event structures are set to lock the front panel until the event completes. While this is a recommended and good setting, it cannot work if the event case contains intereactive code that needs user interaction to proceed. Once your outer loop fires, the front panel is locked. Thus the inner event can never fire. Since the inner loop needs complete before the outer even can complete, nothing further can happen.

All you need is a single outer loop containing a single event structure, possibly with several event cases. The shift register belongs into the outer loop. Don't forget to utilize the timeout event. Simplify!!