Ending Optional Event Structure

[of2006]

Hello 

I am trying to use event structures for a user interface controlled program. I have simple next buttons to go to the next stage which are working fine. However, I am having an issue when trying to implement an option button. So the user doesn't have to use this functionality (to open a seperate settings page) but it's available should they wish to. 

I have attached a simplified VI to show how I am trying to achieve it. I have the option OK button which if pressed, will execute and then the VI will complete when STOP is pressed. If the user should not wish to use the OK button, they can press stop and the VI will end because the STOP button ends the first event, and I have created a second case in the second event structure which does nothing when the STOP is pressed. Without this, the VI would not end because it would wait for the optional button to be pressed. 

This works, however 2 issues; 

1) I believe it's bad practice

2) It is freezing the front panel, even though the structure has completed (i know this as the next set of code starts functioning) and even though I have unticked the "freeze front panel whilst executing" option. 

NB: these errors do not show in the simplified version but I just wanted to demonstrate the code I am using. 

Thanks in advance for any guidance, this is my first time working with event structures and I have not been able to find any good resources to explain them for more advanced use cases. 

[Mark_Yedinak]

You should only use a single event structure. You also need to put it in a while loop,. Do not run your VI using the "continuous Run" button. That is actually running your VI over and over, restarting it every time. It is not running it until you stop the program like you would like. 

[altenbach]

---

@of2006 wrote:

NB: these errors do not show in the simplified version but I just wanted to demonstrate the code I am using. 

---

You obviously simplified it "ad absurdum". This is no longer viable code and since it does no longer show the error, it is pointless to troubleshoot. Right?

Please attach a fully functional version of your code that shows the problem. Preferably, it should be a simple state machine with one toplevel while loop and an event structure (possibly containing several event cases). Then tell us the exact steps how you are using it, what you expect to happen, and what happens instead.

I also recommend the learning resources listed at the top of the forum. I recommend to get more familiar with the basics of dataflow and architecture and postpone the use of event structures until you have more experience.

[of2006]

I have attached the actual code and have removed unrelated functionality. The functionality is such that the user can continue without accessing the admin settings, they can optionally click to view settings but they are locked and then they have the option to unlock them with a password.

Case 1: User presses next without viewing admin settings, Result: front panel is frozen, Next cannot be pressed to end the program

Case 2: User selects to view admin settings, without unlocking them, returns to setup and clicks next, Result: works fine, next can be pressed to end program

Case 3: User selects to view admin settings and then unlocks them (I have set password to 'test'), returns to setup and clicks next, Result: front panel is frozen, next cannot be pressed to end the program. 

I hope that helps

[of2006]

Is anyone able to offer any guidance or is this functionality not possible? 

Thank you

[Intaris]

The "lock UI" option locks the UI at the moment the event is GENERATED, not when it is handled. Otherwise it would make so sense. You cannot "stop" an event structure from enqueuing statically registered UI events (Events registered within the dialog of the Event Structure itself). Even if the Event structure is "stopped", i.e. will never be called again, the events are still going to be queued up and this of course, in combination with the "lock UI" option will automatically freeze your UI until the event is handled, which is never. Congratulations LabVIEW, you played yourself.

I use Dynamic event registration for this. (Drop a "Register for Events" node and wire in any UI elements you want to respond to - then wire this to the dynamic terminal of the Event Structure). That way, when you are finished with the event structure, you can actually wire in a null reference to the event registration refnum (this can even be done from within the event structure handling the event if you wish). This will then prevent any enqueuing of events in the second event handler and essentially side-step the issue you are seeing.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/dynamic_register_event/

I generally disagree with the "only use one event structure" idea. Instead I would say only use one Event structure with statically defined events, everything else (even if handling events of UI elements) should use dynamic registration. Heck, if I had my way, ALL event registration would be dynamic (or at least the ability to "switch off" static events at run-time) would be implemented.

[altenbach]

---

@of2006 wrote:

Is anyone able to offer any guidance or is this functionality not possible? 

---

You need to learn the basics of Dataflow! At this you don't understand it. Currently, you have five event structures. Three in parallel and one inside another event structure and one in another case. This is total garbage code and will never work right.

The above case can only complete once all event structures have fired, which is currently a nightmare. As we said, you need to scrap that program and write a proper state machine with exactly one (or even no) event structures.

If the admin/nonadmin switching exclusively deals with disabling/enabling some controls, that could also be done "out of band" in a parallel loop, independent of the main code. That loop could have a second event structure (exactly one!) and will do nothing unless the admin state is switched or the program terminated. In fact most of my program have such a parallel loop that only deals with UI issues. It will instantly react, no matter what happens in the main state machine.

[Intaris]

Oh lord. Yeah, what Altenbach said. I hadn't even looked at your code but was arguing from an abstract point of view.

Fix what Altenbach has pointed out and forget my advice until then. You have bigger problems.

[BertMcMahan]

To expand a bit on why your code absolutely will not work as is:

All of your event structures are in the same loop. Dataflow says that no construct (loop, subVI, whatever) will return until everything inside of it or feeding it returns. This means two things:

1: Event structures will NOT return until they have processed an event or, if configured to have a timeout case, have timed out. Event structures will execute exactly one frame. In the timeout case, this is the "timeout" frame.

2: Outer loops will NOT return until all event structures inside them return. Thus, your main loop won't return (i.e., move on) until ALL event structures have processed an event.

The above posters are correct- you need to only use one single event structure in a given loop, or really in a given VI*. If you want different cases handled, use different cases in one structure, not multiple structures.

I hope that helps.

*There are definitely times when you want or need multiple event structures in a given VI, but I can't think of a time I've ever needed two in the same *loop*. I would advise that you avoid using multiple event structures in the same VI until you really feel like you "get" single event structures and dynamic event registration. Event registration is a complicated topic, so it's best to just use a single event structure and let LabVIEW handle it automatically when you're first learning.

[of2006]

Thank you Bert for providing a clear explanation. I am aware of why this doesn't work as you have explained, but what I don't know is how to implement it so that the functionality can. I hadn't thought of not using event structures as it's an event driven process. There is no "data flow" because the user can choose any one of these buttons at the same time, that is what I am trying implement, I am not forcing a set "flow". I will have a look at whether case structures are more suitable for this application, I'd imagine it would be an event structure with multiple cases that is in a loop, providing the input to the case structure. 

altenbach, yes you're right I could put the admin functionality outside of the loop but I still have the same issue of "ending" the event structure if the user has chosen not to use this functionality