State machine- when is it too big

[dannyjhu]

At what size, number of states, does a state machine get considered too large?  Is there anything wrong with having 20 or 30 states?  The issues is that I need to have a home state and then the option to run any one of 20 or 30 sub VI when called.  Then after executing the sub VI , return back to the home state and wait for the next instruction.  I could put it together in a state machine or queued state machine and be done but having 20 or 30 states seems like a lot and maybe not the best programming practice. 

Thanks

[crossrulz]

I've had more.  I tend to go with the Queued State Machine approach so that I can easily create chains of states and easily add states in front or abort all of the queued up states.

But as always, it really depends on your application.  You may be able to reduce the number of states by creating parallel Queued Message Handlers.

[johnsold]

I think the limit on the number of states may be constrained by your ability to design the system. If the design on paper becomes incomprehensible or so complex that it is hard to tell what is going on, then you probably need to simplify things.  In part this may depend on how many states can be followed by many other states and how many are followed by only one or very few other states.  If most states return to an idle state unless an error occured and the idle state is where new commands are received from outside the state machine, then large numbers of states may be easily managed.  If every state may be followed by any other state, even a small number of states leads to a very complex next state selection process.

When designing discrete digital hardware implementations of state machines I found that beyond 16 states (or 4 bits) lead to serious implementation issues.  In software state machines can be a good bit larger before becoming a problem.

Lynn

[Ben]

To properly answer taht question we need to define in what context the question "too big" is applied.

In my book "too big" applies to not only the size of the diagram and number of nodes etc but also applies to me ability to clearly communicate to my target audience, what is happening and how. I do not have the luxury of developing code that only I will support. If I develop coe that does everything that is required NOW but is overly complex, the developer that follows behind may not be able to follow my code. When I recieve code from others that are overly complex, the time and expence of figuring what the original developer had in mind can quickly out pace the time it would take me to rewrite in a more concise and understandable form. In that case I have tossed the bulk of teh original code saving only a hanful of useful sub-VIs and rewrote the application.

So the question for me comes down to what I can put a a power Point slide.

No I do not mean the every bit of an application should fit on only one slide. But the functional repesentation of a single VI should fit on one slide. Multiple slides can be used to show waht is going on inside one of the states and in turn more slides for ech of the detailed functions.

Over the years I have developed the ability to spot sections of state daigrams that can be encapsulated and given a descriptive name and rendered as a single high-level operation. Call it top-down programming or whatever you want.

Quoting Dijkstra

"

Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

"

and

"

Simplicity is prerequisite for reliability.

"

Just my two cents,

Ben

[Bob_Schor]

My main LabVIEW RT routine that runs one of our Experiments has 36 States (Turn Sound On, Turn Sound Off, Start Trial, Move Galvo, Exit, etc.).  Organizing it this way immensely improves the "comprehension" of what we are doing, and make adding a new Feature ("Could you make the laser flash at a specified rate?") fairly straight-forward.

Bob Schor

[Gregory]

If you find it hard to navigate the case structure, try out jcarmody's quick drop plugin.

[Alexander_Sobolev]

Very often number of states can be reduced by using parameter, sent together with state control. It can add nested structure, but adds control and keeps similar actions together and separate from another group.

Experiments (I guess) are separate from main vi control, so I would make vi name a parameter and have one state Run experiment in main state machine . If these vis have the same inputs, it might be possible to call them by reference in automated mode without nested case.

[JÞB]

Great Question.

It sounds like you are really looking at avoiding "Code Stench" and yes it is subjective!  Usually resulting from a programming anti-pattern. A State Machine that launches a large number of unrelated functions can grow to be a "God Object"

Those three links will give you a starting point on considering how to avoid poor code and help you answer questions like "Is this "Good SW practice?"

Again, great question! 

[Hooovahh]

Arguments can help for sure, or handling multiple states in one case.  Like I may have a case called "Enable Controls" and "Disable Controls" go to the same case state.  And in there I determine if I should enable or disable the controls, but getting the references to the controls is the same in both states so that part of the code is reused.  Essentially nesting case structures when it makes sense.

Also if you want multiple arguments in something like the JKI state machine I made a small VI that can pull them out.  

https://lavag.org/topic/18945-question-about-the-jki-state-machine/#entry114335

So here I could do something like "Enable Controls >> Stop && Resume"  And it would go to the Enable Controls case, where controls with labels Stop or Resume would be enabled.

But even with these provisions state machines can get quite large, and I find that breaking up the code into modules (actors) that perform dedicated tasks asynchronously can help keep the amount of work in any one state machine to a minimum.

[mikeporter]

Rather than thinking about if it is too big, I think about are all the states needed? Are there any redundant states? Are the any duplicate states? Are you implementing the logic efficiently? Is the work of the state machine cohesive?

If sanity checks like that don't indicate a problem, then it is what it is. Some jobs are just complex.

Mike...