statemachine ARCHITECTURE

[joeycao]

Hello:

I am preparing for my CLD exam, I am seeking advice on the type of architecture I should use during the exam in terms of efficiency and scalability.  Attached are two sample statemachine templates I created, statemachine#1 is usually what I use at work, statemachine#2 was an exeriment.  Please advise.

-Joey Cao

Labview Application Engineer
Design & Assembly Concepts, Inc.
10949 E. Crystal Falls Pkwy.
Leander, TX  78641
512-528-9501 x15
zcao@dac-us.com
www.dac-us.com

[Marc_A]

Personally, I use an enum typedef to hold all possible states. This way I can just select from a dropdown list in each case to pick the possibilities of the next case, and if I want to add or change a case, I can just change the typedef without worrying about changing every instance of it. The queue could be useful if you had a situation where you needed to queue up several states to run, but I've never come across a situation where I would need that.

However, if this is for your CLD, I say do whatever is comfortable to you. You don't want to try something that you're not used to in a time critical situation like that.

[altenbach]

What he said! 🙂

Using plain strings is just asking for problems. The smalles typo, e.g. ("Acquire" vs. "acquire") could give unexpected result.

Your code looks pretty good, with a clean layout. However, you should avoid overlapping wires, e.g. for the "bundle by name" (see picture) the lower case is highly preferred.

Message Edited by altenbach on 01-26-2007 10:08 AM

[tbob]

I prefer queued state machine because there are times when I need to insert several states at one time.  There are other times when I want to insert a state at the head of a queue rather than at the end.  It all depends on the application.  Other times, enums are fine.  Strings are fine also unless you make a typo.  In that case, always add a default case to handle a situation where the incoming string does not match any state.  If you see this when running, you have to find the typo and fix it.  That is why many prefer enums, it avoids typos.

[Jarrod_S.]

You can do case insensitive matches on a case structure controlled by a string. Of course, typos will always be a possibility, so your comment is perfectly valid.

[joeycao]

Typo is not as annoying as having an extra space at the end of the string, you can usually tell when state machine is not transitioning properly and seems to be hanging.

-JC

[Jarrod_S.]

Very true. One good way to debug this would be to have a Default case for the string-controlled Case Structure that does nothing but throw an error and expose the typo.

[Marc_A]

All the more reason to use an enum. I used to use strings, but once I tried it this way I could never go back. Try it and you'll see how much better it is. You can still use a queue, just make the datatype a typedef that holds the state.

[DFGray]

I used typedefed enums most of the time.  However, strings allow for run-time customization that is not easily possible using enums, so I use them in some advanced cases.  To keep your development clean, a default case to catch misspellings is essential (as mentioned above).  In addition, constructor functions to generate the states keep misspellings to a minimum.

[PaulG.]

Enum state machines are my preference, too. If I need to put in a number of state sequences I just use an array of the enums. You can do the same thing with the queue functions. I'm still trying to figure out what the fascination is with the string state machine, i.e. 'queued message handler'. If a spelling mistake or extra space can send my code into oblivion, then all of us might as well go back to programming in a text-based language.