events not triggering on value change

[jfwsigna]

Is there an issue with having multiple event structures in a VI which handle the same events? Specifically, I have a stacked sequence where in one frame there is an event loop (event structure in a while loop) which handles UI buttons and terminates the loop when the correct conditions are met and then moves through to another frame with another event loop which handles the same button events in a slightly different manner and also does some data acquisition, display and output to files.

I have attached a simplified version of the VI which demonstrates the problem. If the second event loop (in frame 3) is enabled, the RUN button does not get handled in the first event loop. If the second event loop is disabled the RUN button does get handled in the first event loop.

Is this something that simply cannot be done in graphical labview? I am more used to doing this sort of programming in C or VB where the event handler determines its behaviour based on some global state variables and perhaps I'm not seeing how to easily achieve this in labview.

[Dennis_Knutson]

You should not have stacked sequence structures and you should not have more than one event structure except in special circumstances. The event structure will always capture events even when inside different frames. You need to redesign your programandand read the help regarding caveats about event structures.

[tst · Accepted solution]

While I wouldn't phrase things as strongly as Dennis did, his points do have merit.

Your specific problem is with a setting set on the value change event in the second structure (a checkbox in the dialog), which tells LV to lock the front panel until the event case completes. Since the event case doesn't complete (it doesn't even start), the FP remains locked and you can't do anything. The key here is in understanding that the registration for the event happens as soon as the VI the event structure is in enters run mode (for simplification here we can just say the VI started running) and from that point on registered events are queued, but you never actually let the event structure execute.

The bandaid patch could be to uncheck the box for that option, but that's not a good solution. A better solution would be to redesign your code in a such a way that you don't have event structures in sequence. There are numerous options for how you can do this. Here's one which is fairly detailed - http://www.notatamelion.com/2015/02/23/building-a-proper-labview-state-machine-design-pattern-pt-1/

In that one you basically have a single event structure and you react to the events based on the state of the system.

[mikeporter · Accepted solution]

Something to always be careful about is trying to carry over into your LabVIEW work too many things that you learn in other languages. I realize that is is painting things with a very broad brush, however ideas and concepts can be good things to learn and carry over, while specific implementations can be very bad things to carry over.

The thing is, every language (human or computer) has its own limitations. For example, most western languages waste a tremendous amount of paper and ink printing things called "vowels". Likewise primative computer languages try to fit everything a computer can do into a linear list of instructions. Now when it comes to problem solving, some aspects of an implementation will always involve working around that language's limitation.

Mike...

PS: Thanks for the mention, tst.

[jfwsigna]

What I didn't understand when I started this project was that registering for events happens when the VI is started, regardless of "where" the event structure(s) are located. I had a suspicion this was happening which is why I posted (though perhaps didn't phrase the question correctly). 

The link to the state machine post was most excellent and helped to complete what I started to do as a redesign (I hadn't thought of using the timeout event in quite that way). Kudos to Mike for a very well done discussion/tutorial. As a hardware electronics engineer I had a good chuckle over the "bad habits" regarding state machine design/use.

And Mike - excellent point about not bringing implementation concepts from another language.... I'm still new to the whole graphical labview universe and don't always recognize when I'm doing that!