multiple event cases

[AlejandroZ]

Altenbach:

Thank you for your recommendations. The simple example I uploaded may indeed be better programmed with the VI you uploaded. However, in the real application, I used a state machine, because depending on the state, the users are allowed to perform certain actions. For example, I do not want users to click the "save data to file" button before an acquisition has taken place, nor do I want them to start controlling a motor before they have setup the sampling parameters.

In that case, I thought that I needed either event structures inside a case structure, or a single event structure, as you have, but with case structures inside each event code, to check the current state, and decide if the code for that event should be run. To make it easily expandable, I created a subVI that took a reference to the tab control, and a page number, to enable all the controls in the page corresponding to the state I was in, and disable all controls of all other pages, so it did not seem like there was a problem with expandability.

So, you think it is better to have a single event structure and check for the state inside each event? I guess I could have designed my application that way... I just started with the normal state machine architecture, and went from there...

Alejandro

[LIONCSU]

Hi,
I encountered the similar problem explicated in accessory. I hope the while loop can be interrupted RANDOM in the START EVENT. Would you illustrate the case?
Thanks,
Regard,
XU

[Johnner]

XU,

It's confusing that you reused altenbach's example above--an example that was already sort of confusing because he had "fixed" it without changing the comments on the front panel to reflect his edits! You may be used to ignoring those comments in this case, but remember that other people will try to understand a VI using any comments that are visible.

The reason your example hangs is exactly what altenbach wrote a few messages above:

---

The main problem in your VI is the fact that your events are set to "lock front panel until event completes". In your case, you fire an event that is in a different case, the front panel locks up and you're stuck because the event cannot be serviced. It's out of the data flow! The quickest workaround would have been to just uncheck the "lock front panel..." option.

---

I've attached a screenshot that shows how to uncheck the "lock front panel until event completes" box for the case that handles your Start button. If you do this, the example might run more like what you expect, in that the user can click the STOP button at the bottom of the VI after it begins counting.

However, this is not really a complete fix for this example, because the VI will still hang if the user clicks the Cancel button (next to the Start button) after he clicks Start. Again, this is the expected LabVIEW behavior after you enable the Event case not to ignore panel events for the Start case, but it's probably not the behavior you want.

To fully resolve the problem, you would have to restructure the whole example. I would suggest taking the "counting" code completely out of the event case and putting it in a separate, parallel while loop. You would also have to introduce some sort of communication between the two loops in this case (local variables, queues, etc.), but this would be the general solution to allowing the counting to be interrupted "at random."

Regards,
John

[LIONCSU]

Johnner:
Thank your immediate explain. I'll act as you advise and reconstructure the program.

Regards,
XU

[Newt]

I didn't look into your code, but generally speaking, you can avoid problems with Event Structures contending with the same event by using dynamic event registration.

To keep other event structures from responding to a FP control, register it dynamically upon entry to the machine containing that particular event handler. When you exit that machine or go into a subsystem, unregister the events, enter the new state machine, and register the appropriate events there. This keeps event response isolated to particular sections of code.

It is not technically necessary to unregister and reregister every time you exit and return to the machine unless the new state architecture uses some of the controls that are registered.  However doing it every time helps with consistency of style and readability.You can minimize the overhead by selectively unregistering only when it was necessary. I found that this is not always worth the effort.

I commonly use multiple nested event-driven state machines with a single user interface. The character and function of the front panel changes with different sections of code, without having to use separate VIs with their own FP. Even then, using a subpanel to load different VIs allow you to keep a common set of controls on the main front panel that operate on all subVIs. Each of these must respond to events from the same control set. The technique I described above allows me to do this with a minimum of trouble. Customers seem to like it.

[shoneill]

Newt,

I'm using LV 6.1, so no dynamic events.  Thanks anyway.

Shane.