State machine struggle

[TG]

Well, it is not really a struggle.

Id just like to see if the State machine I am curerently using is good enough for general purpose work

or is there a better flavor out there.

Ive always had a bit of a snag when it comes to how to handle

errors in a state machine. I wonder if this architecture is the best.

PS: Forgive me if I posted this in the wrong forum.

[Mike Ashe]

Id just like to see if the State machine I am curerently using is good enough for general purpose work

or is there a better flavor out there.

Actually there are probably multiple better flavors, but which to use depends on what you are doing at the moment. Also be aware in accepting advice on state machine design that some people have preferences and beliefs about them that border on fanatical dogma, yours truely included sometimes.

There have been a lot of articles and code examples posted on this subject over the years. have you tried a simple google on LabVIEW and state machine? Same thing on the info-labVIEW archives and here at LAVA? Same thing at NI? Did you look at the LabVIEW \examples?

You might want to start looking at an NI article (with code) about LabVIEW Application Design Patterns

Also: Application Design Patterns: State Machines

And be sure to read this article:

Design Patterns with Event Structure

You could also download and install the OpenG Commander at SourceForge, then afterwards, open it up and study it.

<Fanatical Dogma On>

Both your example and some of the ones above use enums as the input to the CASE in the SM. I prefer text input to the CASE selector as it allows you to parse strings, scripts, etc and use some of that directly. I think it gives better flexibility. Others will argue that with an enum you will never get an unknown state command type of error. I agree with the sentiment, but I give more weight to the flexibility. Just personal preference. YMMV.

The best bet is to learn two or three state-machine design methods, so you can decide which to apply based on your current project, rather than looking for the absolute "best" type of SM and then trying to fit everything into that.

<Fanatical Dogma Off/>

[crelf]

Both your example and some of the ones above use enums as the input to the CASE in the SM. I prefer text input to the CASE selector as it allows you to parse strings, scripts, etc and use some of that directly.

I completely concur - just remeber that case structure selectors are case sensitive by default (you can turn that off with a right click selection), and make sure you have a separate "Default" case with a "Syntax Error" popup for speeling mistkaes you make when coding

[TG]

I completely concur - just remeber that case structure selectors are case sensitive by default (you can turn that off with a right click selection), and make sure you have a separate "Default" case with a "Syntax Error" popup for speeling mistkaes you make when coding

Hey thanks Mike and Crlef

Always good advice and information here!

[crelf]

You're welcome! Isn't LAVA great?!?

[LAVA 1.0 Content]

case structure selectors are case sensitive by default (you can turn that off with a right click selection)

OK. This was posted on the 12th, then Darren says he was speaking with someone last week and learned this little nugget...

[Yair]

OK. This was posted on the 12th, then Darren says he was speaking with someone last week and learned this little nugget...

Sounds legit to me. Most people reading the NI forums don't read the LAVA forums (and vice versa, actually), so there's no reason not to repeat a piece of knowledge learned here.

[Mike Ashe]

I completely concur - ... and make sure you have a separate "Default" case with a "Syntax Error" popup for speeling mistkaes you make when coding

Yep, Default case is a must, however...

if you want/need real flexibility with your state machine you'll use the Default case to implement an interface to call plugin VIs using VI server. That way you can have your "factory-installed" functions/states and also run new "states" that you drop in a plugin directory, scan, list & load at startup time and search for a match in your Default CASE. If you match, run the extended function, if you don't, THEN go to a "syntax" error CASE.

If you move your state decisions outside of the CASE frame(s) into a State Selector subVI that feeds your CASE selector, and then make that state decision a table based lookup (not necessarily even 2D, it can be 3D, xD or a decision-tree) and then make that table reloadable from file or modifiable at run time you can implement a "Psuedo-Infinite State Machine"*

Cheers, :beer:

*See NIWeek-96 "VISTE: Virtual Instrument Scripting Test Executive" presentation.

[crelf]

if you want/need real flexibility with your state machine you'll use the Default case to implement an interface to call plugin VIs using VI server. That way you can have your "factory-installed" functions/states and also run new "states" that you drop in a plugin directory, scan, list & load at startup time and search for a match in your Default CASE. If you match, run the extended function, if you don't, THEN go to a "syntax" error CASE.

:thumbup: That's a really important point and one that I agree with wholeheartedly.

[BigBadWally]

*See NIWeek-96 "VISTE: Virtual Instrument Scripting Test Executive" presentation.

Mike,

Sounds interesting. Where might I find that presentation?

Thanks,

Walt