Hello Lovelies.
I gave this little presentation at GDevCon#2 and the video is linked below. This article briefly explains the presentation and is a good placeholder for the example code.
History and Perspective
I started with a brief history and described the different types of state machine.
This was followed by Turing, Mealy and Moore.
People misconstrue the point of these early state machines and IMO forget that originally they were for reducing switching circuits in telecomms systems. There is therefore a point to some rigour and discussion about them. Whereas in a software system a state will nearly always have data input, this makes them pretty much a Mealy Machine. The State Transition Diagrams we are most used to are Moore State Machines. And you know what, who cares. In software these diagrams are only useful at the initial architecture stage and when in early discussions with an end user.
From a software perspective, if you want rigour use an Harel diagram, it's got everything you need. Me? I just use the diagram above.
Transitions
Most state machine patterns in LabVIEW are either QMHs (not a state machine) or they don't separately describe the transition. This is a shame because it's an enormously useful way to make nice flexible, readable code that matches your diagrams.
I show one way that SSDC describes a state machine with transitions in LabVIEW.
As you can see here that we have a state enum and a transition enum. The transition enum drives the exit from the state.
Language
Simplicity is related to language and language drives design
Adding some language based rigour to our State Machine.
States should be Do-ing something (Present Participle)
Idling, Waiting to Connect, Connecting
Transitions should be an imperative verb.
Connect, Stop, Disconnect
Changing to a present participle has actually effected my expectation about what should be in a state. It's a subtle thing but really helpful.
I'll probably do some more on Language and Software Design in a future article.
Car Wash Example
The state machine diagram looks like this.
The code is attached in LabVIEW 2015 only Loop 4 is the state machine. Have a play, use it if you like it, don't use it if you don't. I've used this template in loads of projects from the tiny to the huge. State machines are more useful for control systems, but I nearly always find a use for them.
Don't put Everything Everywhere!
Use Event loops to fire transitions, you want to get out of events quickly!
Use the UI QMH to just update the UI, a responsive UI will be your reward.
Put everything you can in the state machine!.
Lots of Love
Steve
Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.