Events/state machine

[Clint_Eastwood1000]

 

I'm using something similar to your example..do/while>event>state machine..One of my menu items is EXIT.  When the EXIT Menu button is pressed (EVENT CHANGES STATE) it goes to that event monitoring the exit button.  Inside the event structure is a boolean setting the Loop Condition to true, stopping the loop.  I also have Quit Labview which also closes the program when EXIT is hit.   So I don't understand what is meant by "Because your event case isn't allowed to stop."

Doesn't an event structure "wait" until...in my case.. a menu button is hit then..again in my case..run ( statemachine) every condition in my event?  I guess I don't understand all the functionality of the event structure.  I'm using it as an event..the menu button is pressed.  Then run each case in the event.  I'm confused as you why you would want an event inside a statemachine.  I tried it and didn't get very far w the logic for my particular case.

Thanks..

[VItan]

---

@Clint_Eastwood1000 wrote:

... I don't understand what is meant by "Because your event case isn't allowed to stop."

---

Because you described your design as having a while loop within your event structure's diagram(s), those diagrams have to run to completion before you can exit the event structure and run your main loop again, which would mean running the event structure again and handling the next event.

[crossrulz]

---

@Clint_Eastwood1000 wrote:

 I'm using something similar to your example..do/while>event>state machine..One of my menu items is EXIT.  When the EXIT Menu button is pressed (EVENT CHANGES STATE) it goes to that event monitoring the exit button.  Inside the event structure is a boolean setting the Loop Condition to true, stopping the loop.  I also have Quit Labview which also closes the program when EXIT is hit.   So I don't understand what is meant by "Because your event case isn't allowed to stop."

Doesn't an event structure "wait" until...in my case.. a menu button is hit then..again in my case..run ( statemachine) every condition in my event?  I guess I don't understand all the functionality of the event structure.  I'm using it as an event..the menu button is pressed.  Then run each case in the event.  I'm confused as you why you would want an event inside a statemachine.  I tried it and didn't get very far w the logic for my particular case.

Thanks..

---

This is sounding like a massive misunderstanding of what your code looks like.  Post some example code of what you have.  Based on your description, you have a while loop state machine in each of your event cases.  This would mean that you would not be able to monitor for the button presses since you are still running inside of an event case.

[Clint_Eastwood1000]

So here is my program.  Its stripped down a bit but I hope the idea is still there.

[crossrulz]

This is not what we showed you to do.  We are back to the fact that the Event Structure must complete what is inside the running case before the outter loop can iterate to allow the event structure to handle the next event.  You need to combine all of your code into a single state machine.  Yes, that means combining all of those enum values into a single enum.

[Eric1977]

I'll add to crossrulz post. Use the "State Machine Fundamentals.vi" in the Examples area to base your State Machine off of.

[Bob_Schor]

While it is possible to have something like a State Machine inside an Event Loop, I've found that having an Event loop that mostly monitors Events (like changes to Front Panel Controls) and a parallel Queued Message Handler (which you can consider as either a State Machine or an Action Engine, depending on how successive "States", or Messages, are generated), with the Event loop "calling" the QMH by (you guessed it) putting a Message (and parameters, if necessary) on the Message Queue.  Very flexible, easy to understand, easy to explain and debug (!!), and I think there's even a Project Template that has much of the code already implemented (though you are free to "roll your own").

BS

[Clint_Eastwood1000]

Thanks everyone.  Back to the drawing board..

[Clint_Eastwood1000]

The code I posted was my code before your comments..One more thing..crossrulz you said :"Based on your description, you have a while loop state machine in each of your event cases.  This would mean that you would not be able to monitor for the button presses since you are still running inside of an event case." 

This is exactly what I want to happen.  I don't want the cal menu button or the self test menu button to do anything until I've completed functional test ( state to state) .  Ones the user selects functional test button menu I want whats inside the statemachine in the event to complete  before I monitor for another event such as cla button or self test button being pressed.  Its sounds like from your comments that this must be a bad thing to do.  I guess I could understand a state machine (SM)  for my project but what is the event structure doing inside the SM ??  Once I've selected the "state" it runs the different states independently of user action.  I'll look at State Machine Fundamentals.vi

Thank you..

[VItan]

---

@Clint_Eastwood1000 wrote:

...

I don't want the cal menu button or the self test menu button to do anything until I've completed functional test ( state to state) .  Ones the user selects functional test button menu I want whats inside the statemachine in the event to complete  before I monitor for another event such as cla button or self test button being pressed.  Its sounds like from your comments that this must be a bad thing to do.

---

The reason that having a state machine loop that starts and runs to completion within the diagram of an event structure's case is generally considered a bad thing to do is that it makes your user interface that is handled through this event structure unresponsive while you are performing one of your actions.  For example in your case you originally specifically said that you wanted to have an ABORT button press perform a shutdown.  If you do not handle any events until you finish your activity, then you will not handle the ABORT button press event until the activity is finished.

You may want to consider programmatically disabling the buttons that you don't want the user to be able to press while an activity is running.

For example, if you have three buttons, "Test 1", "Test 2", and "ABORT", you could have an event structure that watches for any of the three buttons.  Test 1 and Test 2 button presses cause the respective test to start and then disable the buttons from being pressed again.  When the test is finished, the buttons are reenabled.  The ABORT button is always enabled, and stops any running test if pressed.

In this design, you could use either a "state machine with case structure inside the event structure's timeout case" or an "event structure producer with QMH state machine consumer".