Unexpected behaviour of Queued Driven State Machine

[Martin11]

Hello everybody,

I'm currently working on the control of a coffee machine. A user should be able to decide if to brew one or two cups of coffee. The code is based on the QSM PC architecture. After initialization the state changes to "idle". Due to future error handling "idle" is added to the queue again and again. If one of the two buttons is pressed, the state changes to "brew". In the example I'd like to stay in the "brew" state. Later, data (produced in subprocesses - something like temperature or pressure) shall be used to decide when to leave the "brew" state and return to "idle". 

When pressing the "brew button" following behaviour is observed: 

First, the numer of elements in the queue is increasing by one everytime the button is pressed. I expected one or zero elements in the queue.

Second, the states are changing all the time (idle - brew one - idle ...). 

Does anybody find the problem and may explain it to me?

Is the basic architecutre applicable in my case, or does anybody have another suggestion?

Thanks, 

Martin

[Bob_Schor]

I suspect the root of your problem is a misunderstanding (which, I must confess, I also share) about the true definition of a State Machine (as my students who have a Computer Science background are quick to inform me) and the usual implementation of what I've called a "State Machine" using an architecture like the QSM.  

The basic culprit here is the Queue.  By definition/convention, a State Machine has a Transition Rule that can take it to a Next State.  In particular, you can only specify one State ahead, which implies you are dealing with a Queue of length 1.  Note that the Simple State Machine pattern that comes with LabVIEW uses a Shift Register for the Next State, something that acts like a Queue of length 1.

What's wrong with putting two things on the Queue?  Nothing, really, but then you aren't dealing with a State Machine.  When you start executing the first "State" on your Queue, you've taken away its ability to handle its own Transition as you've already decided what is next (because you put that on the Queue as well).

You might consider looking into the LabVIEW StateChart Module, which looks (to me) like an architecture for a State Machine that handles Events and transition rules in an interesting way.  [Final confession -- I've not (yet) utilized it for my Projects, but feel that maybe I should study it more closely ...]

Bob Schor

[drjdpowell]

As Bob says, there is no such thing as a "Queued State Machine" as it is meaningless to queue "state".  What you can queue are "actions" (or "commands" or "triggers" or "stimulus").   So make a separate, non-queued, "state" enum in a shift register with your "idle" and "brew" states, and have your queued enum have actions like "start brewing" (which changes the state enum to "brew") or "continue with current state", which does whatever actions are required by current state.