State machine with events

[GaryN]

I have a simple state machine with only two states. Inside the machine I have an event structure for both states. I start in an initial state and after the user does something the other state is selected. But here's where the problem comes in. The event handler in the secondary state runs automatically based on what was done in the first state. If a button is clicked in state one, state 2 reacts to it as well when it is its turn. Any reason for this? Can the same event structure just not be in two locations? Any suggestions?

[Will.D]

No, the same event structure cannot be used in two different locations.  One of the caveats to using event structures (in the manual and LabVIEW help), states that you should never have more than one event structure in any one vi.

If you post your code I'm sure a number of people would be willing to help find a way around your problem though...

Message Edited by Novatron on 07-14-2005 02:53 PM

[GaryN]

---

@Novatron wrote:
No, the same event structure cannot be used in two different locations.  One of the caveats to using event structures (in the manual and LabVIEW help), states that you should never have more than one event structure in any one vi.

If you post your code I'm sure a number of people would be willing to help find a way around your problem though...

Message Edited by Novatron on 07-14-2005 02:53 PM

---

Thanks. I've already started splitting the two state's internals into subVIs because i sorta figured that was the case. In all honesty I probably should have been doing that from the get go. I guess that's why it's good practice to do some planning before you start coding. Thanks again.

Gary

[Jarrod_S.]

Just to split hairs here: NI recommends not using two event structures within a single loop. A VI can have multiple event structures if carefully planned. I'm not 100% sure what the nature of your problem is. I believe you're saying that the second state fires automatically, when it should be waiting for some user event before it fires.

Just keep in mind that registered events are placed in a buffer to be executed whenever possible.

[Kevin_Price]

Jarrod,

Regarding that hair-splitting: Is it "officially" ok to have two event structures inside independent loops within a single VI AND to have both event structures register to receive a "value change" event from, say, a "Quit" button?  This way a single "Quit" button could terminate both loops cleanly without resorting to local variables, property nodes, queues, notifiers, or whatever else.

I've actually tried this many times when prototyping.  It's always worked just fine and I've never encountered any problems.  But is this method supported officially or is it just an accidental quirk that could go away?

-Kevin P.

[tst]

Kevin, I don't see any reason for it to go away. An event structure is supposed to react to all the events it has registered for, regardless of what other event structures do. If you read the manual (chapter 9), you will see that this is "officially" so:

Each Event structure and Register For Events node on the block diagram owns a queue that LabVIEW uses to store events. When an event occurs, LabVIEW places a copy of the event into each queue registered for that event. An Event structure handles all events in its queue and the events in the queues of any Register For Events nodes that you wired to the dynamic event terminals of the Event structure. LabVIEW uses these queues to ensure that events are reliably delivered to each registered Event structure in the order the events occur.

The only place where they do affect each other is when you use filter events:

LabVIEW sends filter events sequentially to each Event structure configured for the event. The order in which LabVIEW sends the event to each Event structure depends on the order in which the events were registered..

. Each Event structure must complete its event case for the event before LabVIEW can notify the next Event structure. If an Event structure case changes any of the event data, LabVIEW passes the changed data to subsequent Event structures in the chain. If an Event structure in the chain discards the event, LabVIEW does not pass the event to any Event structures remaining in the chain. LabVIEW completes processing the user action which triggered the event only after all configured Event structures handle the event without discarding it.

I'm assuming that all the event data is kept in this queue, so if you are processing a value change event 20 seconds after it happened, the values you will get from OldVal and NewVal will not be the current values, but the values from 20 seconds ago (although I haven't checked this).

[Ben]

Greg McKaskle wrote when the event structures first came out that it was a bad idea to have multiple event structures. I have no experience to share reagrading multiple event structures.

I am questioning why more than one event structue is required. I will usually only use the event structure to handle the user interface and pass extended task to a slave process via a queue. (Exception, force sequncing of events).

So, why more than one event structure?

Ben

[tbob]

I think that maybe one reason why someone would use two event structures is that the person is not familiar with event structures and how to use them.  Perhaps the programmer is thinking that he needs an event structure for each event to be handled, not knowing that one event structure can handle multiple events.  Newcomers need to learn the difference between an "event structure" and "event cases".  For the benefit of those newcomers, here is a small tutorial.

Only one event structure is needed.  Just as you can add cases to a case structure by right clicking the border and selecting add case, you can add event cases to the one event structure by right clicking the border and selecting add event.  Also, one event case can handle multiple events.  Lets say that you want to execute the same code when a user presses the Abort button or the Quit button.  Inside the window where the event is being defined (button down, mouse up, value change, etc), there is a + sign at the top to add another event to the same case.  So you can have two events that will call the same case.  Also, the event structure will wait for an event that is defined inside its structure, execute the case when the event happens, then the event structure is done, just like a case structure.  That is why you have to put the event structure inside a loop so that it can get ready for the next event.  Other wise, when the first event that happens is executed, the event structure will no longer execute and later events will go by unprocessed.  Another point for beginners is that the event structure will wait for that first event.  The vi will not end unless an event takes place.  The Timeout event can be used so that the vi can end even if no other event happens.  Just wire a value to the timer.  That way, an event has taken place (the timeout event) and the vi can end without any other event happening.  When I first started, I have seen my vi hang up because the event structure had no timout case, and it was sitting there waiting for an event to happen.  Most people will use a stop event so that the user can press a stop button to quit the vi.  A boolean is wired to the loop condition, when this event fires, to stop the loop.  If using this, no timeout is necessary (unless you have other uses for the timeout, which is quite possible).  I hope this clears up some confusion with beginners.