Events/state machine

[Clint_Eastwood1000]

I have a  state machine in side of an Event Structure.  The user selects, for example, a menu driven event such as Funtional ( boolean chgs state) or Self Test etc.  Once that event is selected the code runs changing from one state to the next until all the states have completed and the codes waits for another event to occur.  One of my requirements is to make sure that the user doesn't open a door.  The door is tied to an interlock read by a boolean in my code.  I also have to constantly monitor an ABORT button (boolean) also.  Is there a way to constantly monitor ABORT and the interlocks while running the events and then the state machines so that if either of these booleans become true I can run another vi ( ie: "soft shutdown"??)

Thanks..

[Michel_Gauvin]

Yes it's possible. Now, if you want a detail answered post some VI's.

[crossrulz]

---

@Clint_Eastwood1000 wrote:

I have a  state machine in side of an Event Structure.

---

That is your problem.  You have your architecture in-side-out.  Your Event Structure should be inside of your state machine.  I typically use a state called "Idle" or "Check For Events".  Inside of that event is my event structure to handle the GUI.  So in your normal processing, through your state machine, you just need to go to the Idle state every so often with the timeout set to 0 just to check for the abort or open door controls.  You can then transition to the shutdown state if one of those events happen.

[mikeporter]

What you are looking for are daq events, if your card supports it, you can fire a LabVIEW event when a signal changes state. Check the examples.

Mike...

[mikeporter]

Actually, he has the structure as it should be. I have seen too many examples of programs that lock up because the developer forgot to get back and check for events. As I have demonstrated, building a state machine in the timeout event is a powerful way of structuring things.

Mike...

[RavensFan]

Mike,  that is hard to say without seeing the actual code.

A state machine inside the timeout event makes sense, as long as you are only talking about the case structure itself.  If there is a while loop inside that timeout event that wraps up the state machine case structure, then it probably won't work so well.

And if the original poster forgot to put the event structure inside of a master while loop, then they really have problems.

[crossrulz]

---

@mikeporter wrote:
building a state machine in the timeout event is a powerful way of structuring things.

---

(I added emphasis on the important part here)  Now that is an alternative worth looking into.  I have my reservations, but I think I have an application that would benefit from this.  Looks like I actually need to read your blog one of these days.

[crossrulz]

Just played around really quick with making a template based on Mike's idea here.  If people only set the states in the events, I don't see anything really wrong with this setup.  As always, it depends on the application.

[Clint_Eastwood1000]

Sorry everyone I was NEVER notified of any replies.  Just happened to check back.  For propietary reasons I can't post code but I can give a general example.  I have a 4 menu button front panel that monitors which button is pressed...changes state.  Self test Main test STOP and Calibration.  This is my event structure inside a do while loop.  When any of these buttons are pressed (the event) the state machines inside the event executes.  The state machine inside the event is also inside a do while loop.  My question is can I be executing the statemachine while also monitoring a Boolean ( ABORT) button so that if the user hits a SW Abort another vi is executed like a "soft shut down"??

[crossrulz]

---

@Clint_Eastwood1000 wrote:

My question is can I be executing the statemachine while also monitoring a Boolean ( ABORT) button so that if the user hits a SW Abort another vi is executed like a "soft shut down"??

---

Not really with your event structure.  Why?  Because your event case isn't allowed to stop.  You need to move your state machines out of the event structure cases and have 1 state machine that can work for all of the cases.  This does sound like a good situation where Mike's version of putting your states inside of the Timeout event case would work really well.  I quickly make a start of the code in my previous post.