multiple event cases

[shoneill]

I have a general question which I'm sure has been answered before, but I can't find a post referring to what I want to know.

My question is:

Why is it recommended to have only one event case per VI?

If I have two event cases, but they both react to different events, will this lead to a catastrophic meltdown or is the "one event case" rule a bit like the "no local variables" rule which is kind of a soft rule....

I've stumbled across an interesting answer about functional globals and queue-based event handling. I think I kind of get the functional global part, but I'm not quite so sure about the queue-based event handling.

Before I start brushing up on these aspects (Ok, functional globals are a good thing regardless), I'd like to be able to work out the path of least resistance for my current application.

Can anyone give me a quick pointer or a source of further information?

Thanks

Shane.

[becktho]

Hi Shane

If you have a look at the labview help (search for "Caveats and Recommendations when Using Events in LabVIEW") you may find an answer.

It should be possible to work with two or more event-structures (if they are not in the same loop). I think it depends on your application, but I would still just use one structure, because you have all events handled on one location and if you just enqueue elements or send messages, there shouldn't be any performance problem.

That's my opinion ;).

Thomas

[shoneill]

OK,

I looked at the help, and see nothing to stop me using more than one event case in my application as I don't break the rules

1) Using multiple cases for the same event.
2) having more than one event case in the same loop.

I'm interested if this is right, because I don't want to get into any bad habits (I have enough already), but my program seems to function just as I want it to. Hmmm.

Thanks

Shane.

[Dr._Imad]

not exactly what your looking for, but I have used nested events structures, carefully and it works. I used event structures to fire vi's containg event structures. (the called vi is set in dialog mode, and has event structures in it)

[JoshMonkey]

I'm still a beginner in LB and have only used LV for no more than a few months.

For my project with LB, I am actually using multiple event structures in one vi. However, I have all the front panel objects irrelevent to the current process disabled and enabled by stages so that the program doesn't step into any of the events unecessarily.

[Kevin_Price]

I'll confess too. I thought I remembered reading somewhere that when an event happens, its associated data would be sent to *all* the handlers that had registered for it, implying that one may choose to have two independent event structures that each respond to the same event.

I set up a quick-and-dirty test program the other day that used a single "Stop" button's "change value" event to terminate my 2 independent while loops. One of the loops updated a user display pretty frequently while the other would occasionally do some processing, change settings, and write to disk.

It has worked just fine, but is it still a bad idea? Am I hallucinating about my memory? Or was that stuff meant primarily for dynamic user events as opposed to OS events?

-Kevin P,
also trying not to form a new habit if it's a bad one

[RobCole]

Okay, it IS possible to have 2 event handlers in one VI.

If both event handlers look at different events, it should work okay.

If you have 2 event handlers looking for the same event, you can not predict which will see the event first. Non-deterministic function can cause all sorts of problems. If you're looking at a button and one of the event handlers has the terminal in it (button function is latch) or the event case resets the button, then the button may be reset before the other event handler even notices it.

Yes, it's possible if you're very careful.

A better solution is to use one event handler and perhaps 2 state machines that use queues for what state to go to. Just queue up a state for one of the state machines to execute. Wait on notifier works, but would choke if you have multiple events happening quickly, so I prefer queues for this type of work. The queued state machine also gives you the option to call multiple states in any order (or have one state machine queue something up for the other).

Rob

[AlejandroZ]

Hello,

I ran into a problem using multiple event structures in the same VI some time ago while I was constructing an application, and I was convinced it was a bug. So I created some small VIs to demonstrate the bug to NI's R&D when I contacted them with the problem. They responded that it was not a bug, but expected behaviour of using several event structures in the same VI.

The situation was that I had a state-machine structure, with event structures in different states of the machine. The "bug" was that the VI was catching events configured in event structures that should not be running at the time, because the VI was in another state. But the VI was catching the event anyway, locking the front panel, but not executing the code, since the VI was not in that state.

The only solution at that point was to use CTRL-ALT-DEL to shut down LabVIEW!!

Here, I attach the VI with the problem, and the work-around I had to implement, which in this case was to disable all controls which generated events which corresponded to other states of the state-machine.

I think it illustrates the disadvantages of using several event structures pretty well.

NOTE: Make SURE you open the block diagram before running the VI, so that you can STOP the VI using the stop button, because the front panel may easily become locked.

Hope this helps,

Alejandro

[altenbach]

Alejandro, it is a really bad idea to hide multiple event structures in various cases of the same case structure as you have done. This is against the spirit of the event structure.

The lockup behavior is in no way "inexplicable", but actually quite logical. 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.

Still, I consider this VI design seriously flawed. Your workaround simply adds an additional layer of unecessary complexity, maken the VI even harder to debug and expand. A simple example to duplicate the correct funtionality with a single event structure and NO case structure is attached. It does not lock up! 🙂

[altenbach]

Shane,

There is nothing wrong with having multiple event structures in a single VI if you know what you are doing. You are a fantastic programmer (see your LV challenge entries! ;)) so I trust your judgement.

Many of my VIs have multiple event structures, the main event structure services the UI. Other event structure are fired to execute independent background calculations or to do scheduled maintenance operations using a long timeout event. They often also contain an event to reset their loop (shift registers, etc.) back to a defined state. All event structures have a stop event tied to a single shared FP button (Yes, having multiple event structures fired by the same event is fine!). This allows immediate stopping of all loops without the use of locals and immediately breaking all long timeouts.

My personal strict policy is that each event structure must be able to "breathe" independently in it's own while loop. What is the benefit of an event if it cannot execute after trigger because of other issues? It should not be tied to any data dependency (i.e. it should not have to wait for data flow that might never arrive), should not be hidden in a case structure, hidden in another event structure or otherwise obstructed. Not adhering to this requires tiresome micromanaging of the code, something I am not willing to do. LabVIEW programming is supposed to be fun. 🙂