LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
mike_nrao

Provide a proper State Machine template with LabVIEW

Status: New

Based on discussion at the CLA Summit with Dave Snyder and others: The 'Standard State Machine' available through the 'New...' dialog is not a state machine at all.  It needs to be called something else.  Other implementations commonly referred to as 'state machine' are in fact not; As has been pointed out by Elijah Kerry: "State Machine is a misappropriated name for a Queued Message Handler."

 

I think this is worse than misappropriated; it's actually quite misleading.  The main problem is that Commands (or Messages) and States are two different things and shouldn't be used interchangeably.  

 

I propose LabVIEW ship with something similar to what I attached.  Although it's lacking many of the features that a full-blown state machine ought to have, it does capture the basic premise: "A state describes a behavioral node of the system in which it is waiting for a trigger to execute a transition." [http://en.wikipedia.org/wiki/Finite-state_machine]

 

Those of you with knowledge on this subject, please comment here with suggestions for this code that might bridge the gap in making this a useful template for people who understand state machine design but also still keep it as a good starting point and learning tool for beginners.

The attached code is multiple files, since I used type defs for States and Commands.  Replacing these with string constants would quickly turn the template into a single VI. 

 

stateMachineFrontPanel.png

 

simpleStateMachineBlockDiagram.png

6 Comments
jcarmody
Trusted Enthusiast

@mike_nrao wrote:

Based on discussion at the CLA Summit with Dave Snyder and others: The 'Standard State Machine' available through the 'New...' dialog is not a state machine at all.  It needs to be called something else.  [...]


 

"Hector" has been suggested.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Daklu
Active Participant

Actually, I think the Standard State Machine template is appropriate for what it is.  It's not a particularly useful template for me (I think it would be more useful as drag and drop code from the palette,) but it does correctly illustrate how to start building a very simple state machine.  What the template doesn't do is illustrate how to correctly integrate a messaging system with the state machine.

 

At some point in the past the QSM emerged as the common solution to messaging with a state machine loop.  Many QSM implementations are derivatives of the Producer/Consumer templates.  However, those templates are not incorrect either.  The problems arise when developers modify the Producer/Consumer template in ways it was not intended, such as expecting the consumer to behave like a "real" state machine, having the consumer queue its own messages, or having correct consumer behavior depend on a message sequencing.

 

So I agree NI needs communicate better ways to integrate messaging into state machines, and a template may be a starting point, but the real key is getting developers to understand why and when particular patterns should be used.

Broken_Arrow
Active Participant

Often, "State Machines" are in fact Sequencers.

Richard






MarkCG
Active Participant

They could make the StateChart module part of the standard development system... It's a very nice way to make state machines, and has queues for asynchronous operation / trigger events. I've never heard of anyone using as an add-on... 

Daklu
Active Participant

Mike,

 

I was reading this again and realized your suggested template is different from what I was trying to describe to you at the summit.  (Coding on the back of a business card leaves a lot to be desired.)  Your template is definitely better than the currently used QSM practices.  It separates the state enum from the command enum, turning the "commands" into "requests" and leaving the state machine in control of it's own transitions.  Message filtering is a good thing, and that design will work for sleepy state machines--state machines that sleep until they receive a message, process it, and go back to sleep until the next message arrives.

 

However, there are some things about that template that may lead to complications.  Usually I want my state machines to execute an ongoing process in at least one state and be sleepy in other states.  Dequeuing the messages outside of the State case structure creates difficulties implementing that.  An ongoing process requires a short timeout on the dequeue function to be responsive and avoid blocking.  On the other hand if we're in a state that we want to sleep until it receives a message, we'd prefer to leave the timeout unwired.  I've seen shift registers wired to the timeout as a way to implement changing timeouts, but that leads to my other issue...

 

I think it is much easier to read and sustain the code when the code structure mimics the state machine structure.  In other words, I like it when code defining a state is clearly distinguishable from the code defining other states.  Each state should be self-contained and distinct.  In the template implementation, after a state handles a message it "leaves" the state, waits for another message, and "reenters" the state.  That makes it harder to implement advanced state machine concepts like Entry Actions, Exit Actions, and Transition Actions.  You can do it by adding things like "StateA-EntryActions" to your state enum, but it ends up distributing the state's complete behavior across multiple frames and is more prone to sequencing errors.

 

Here's a snapshot illustrating the intent of the state machine implementation I typically use.  It's not exactly what I use, but the ideas are the same.  (I use LapDog instead of native queues and--depending on the project--wrap each state in a class.)  Entry and Exit actions aren't shown.  They would be placed in the States case structure before and after the State Execution Loop.  I can look at a single States frame and discover everything I need to know about that state.  I'm sure it's no surprise I prefer this kind of implementation, but I do recognize it is largely a matter of style.

 

Event Based State Machine.PNG

Daklu
Active Participant

@jcarmody wrote:

"Hector" has been suggested.



LOL... I'm surprised anyone remembers that.