state machine

[tbob]

"I find subvi's and enum easier to understand"

Huh???  Why create a subvi when the code is simple enough to put it into the main vi.  That is certainly adding a level of complexity.  So is using enums instead of strings.

Why would you want to complicate things if you are a novice?  You can try this for practice if you like.  My time as a volunteer is limited.

Create your enum structure, and use it to replace the strings.  Put your subvi back in place of the code in the No Event case.  To me this is harder and very unnecessary.

[mikeporter]

Is this just a learning exercise for state-machines, or are you working towards something. The reason I'm asking is that this type of thing cries out for an event-driven structure. Put your initialization code (if there is still any needed) outside the loop to the left, put an event structure inside the loop instead of the case, and create a value-change event in the event structure for each button. You're done.

No polling for button presses, no shift registers for passing state information. In fact, no overhead of any kind...

Mike...

[mikeporter]

Excuse me for sticking my oar in here, but given the structure of this example, in what possible way are strings "easier" than enums? But more to the point, ease isn't the issue here.  Using a string to carry state information in a situation like this is just plain bad programming practice.

Mike...

[tst]

LV6, Mike. No events.

[tbob]

To answer Mike's question about strings being easier than enums:  It is really a matter of preference.  I find strings easier because I can easily create one string at a time.  With enums, the exact enum structure with all of its elements must be used when calling subvi's and such.  If you add an element, you must also modify every place the enum structure appears.  I do use enums where it is convenient.  For state machines, it is so easy to add another state by just adding another case and one string.  Yes you can add another element to the enum and add another case as well, but then you have to hunt down every place that enum structure is used and update it.  I find it easier to use strings to hold the states, especially when using a queue.  The advantage of using a queue in a state machine is that you can insert states ahead of what is already queued if need be.  You can insert multiple states to be queued in one step.  Try doing that with an enum structure.  It can be done, but it is certainly more complex than a simple string.

[Kevin_Price]

tbob,

Much of the hassle you describe with updating all the enum instances will be taken care of auto-magically if you customize the enum as a typedef when you first create it.  When you want to add a state, just add it to the customized control, click on File-->Apply Changes, and hey presto! -- all the instances get updated.

I've had some situations where the "grammar" needed to be defined at run-time and enums just weren't feasible (because you can't write to their "strings[]" property).  But generally I've come to greatly prefer enums due to a few occasions where I've fed a "quit" to a routine that was looking for "Quit " or "exit".

FWIW,

-Kevin P.

[tbob]

I am certainly not advocating to not use enums, especially since I use them quite often.  Like I said before, it is a matter of preference.  I can see the problem with Quit vs quit.  To alleviate that, one can use the To Upper function and put cases in all uppers.  But for state machines, I still prefer to create a string constant (Functions - Strings - string constant) than to create a typedef, open up the control editor, add a new element, click File - Apply Changes.  Yikes!

[alkazaa]

I also prefer the string over the enums. To circumvent problems due to misspelling (Quit vs. quit e.g.) I have in the case structure where the string is fed into the "" (emtpy string) as default. Every illegal string goes here and produeces an error message like 'Illegal String 'Quit' encountered' so you get some feedback what went wrong.

-Franz