Looping initialise state in queued state machine

[johndoe773]

I am building an application where I have a standard state machine while loop. Due to benefits of queued state machines I would like to change to the queued version. However I have reached the following snag.

The attached picture "SM1.png" shows the standard state machine.

In my application I wait for a user to press the "Connect"-button. The program keeps looping the"Initialise"-state until that button is pressed. Afterwards, the "Run"-state is set. Then the state machine enables a variety of user options (move motor, disconnect motor, ...).

After the "disconnect"-button is pressed the "initialise"-state is looped again until the user presses the "Connect"-button.

With the queued state machine (here) the states can be accessed randomly. The "halt"- and "resume"-buttons can be pressed before the "start"-button. In this example application it is not vital to press the "start"-button first.

In my application however it is vital. The motor needs to pass the "initialised"- and "connected"-state before you can pass the "disconnect"- or "move"-state.

How can I cleanly achieve the looping "Initialise"-state with queued state machines?

[Bob_Schor]

OK, I just wrote a long tirade about your post, mainly because I didn't read it carefully enough.  My first point, however, is still true -- DON'T POST PICTURES OF CODE!  Post the actual (and entire) VI, please.

You make a good point about the QSM allowing (in principle) the States to be executed in any old order, including Run before Initialize, or Stop before Start.  One way that I use to prevent this unwanted behavior is to use the "Visible" Property of the Controls.  When the Program starts, the Initialize State makes all the Controls invisible except the ones you want the User to change.  Suppose one was "Sample Size".  OK, when you push it, it should change the Sample Size.  But once you push "Run", you don't want to be able to change "Sample Size", so either make it "Invisible" (Visible property False) or set it to be Disabled (so it's visible, but unchangable).  Similarly, when you enter the next State, you can enable the controls appropriate for it.

When you design your State Machine this way, each "State" might have two or three sub-States -- one to "initialize" the State (turn Controls on or off, as discussed above), which transitions to the "Loop" State (which does whatever over and over by calling itself), and finally you might have a "Cleanup" State that gets ready for whatever comes next.  Trust me, it will make for much cleaner, easier-to-debug code.

Bob Schor

Bob Schor

[johndoe773]

Dear Bob,

My code is everything but presentable/runable at this time. That is why I could not upload. The uploaded picture was uploaded to aid the comprehensibility of my question.

To comply with your request I will upload the linked example code that I have adapted.

Inside the attached file is

- Queued SM - The queued state machine example

- UnQueued SM - The quick and dirty adapted state machine without queues

- Queued SM_Locked - The queued state machine example with your posted solution integrated.

During making and running this example I see that there is an unwanted effect in my program where the button states have a race condition during execution. Don't hold it against me please.

Your posted solution could indeed be the winning ticket. I will need to still find a clean solution to integrate this.

[Bob_Schor]

Two suggestions.  First, don't wire 0 or 2 to the Disabled property (what does 0 mean?) -- instead, right-click the input, say "Create Constant" (which will put the default Enum, "Enabled", there), then change it to Disabled, or Disabled and Greyed Out if needed.  Presto, instant Documentation and much clarity.

Second, put the Halt, Start, and Resume switches inside their respective Event Cases.  These are Latch when Released, and you only want to Read them when they are triggered by their Event.

I don't think you will have any Race Conditions here ...

Bob Schor

P.S. -- I've only looked at QSM Locked. 

[johndoe773 · Accepted solution]

For further reference, this is how I fixed my issue.

I used the method Bob has provided. It is everything but clean but it works. You have to remember what to enable where and there are a lot of buttons to change the state of.

So disable the buttons that interact with the states that should not be triggered and enable the buttons when the states can be triggered.