State Machines Done Right

[swatts]

Hello All

Not long until my USA tour (Chicago -> Albuquerque -> Austin) and I'm very much looking forward to it. So I'm busy clearing down my workload and looky here I have an hour to spare. I'm going to use it to write about state machines.

So first point is a Queued Message Handler (QMH) is NOT a state machine and our standard architecture that pretty much works for everything consists of...

Event Structure

State Machine

QMH for UI

0>more QMHs for error handing or communications or printing or whatever.

Optionally dialogs can have their own state machines and QMHs if they are of the wizard type.

We like our state machines match a State Transition Diagram and that means they have a state (doing something) and a transition (instruction to do something else).

Like this.

Whereas the classic LabVIEW state machine looks like this (replace enums with strings if you enjoy a little more guesswork/freedom in your designs)

You can see that there's state info, but no transition info, in fact the transition is at the point where the tunnel leaves the case structure.

In our way of doing it we have a transition queue that we can do multiple things too. It can just hold up the state, it can timeout and go round again or in the example below it just loops until told not to.

So in the above example it gets confirmation from the host that the port is opened and that is the transition trigger to the next state.

The snippet maps nicely to the following diagram.

Which is all nice and neat.

Anyway if you're in Albuquerque 21st July-28th July 2018 DM me and I'll let you buy me a drink for all the articles I write, or maybe I should buy you a drink for reading them

Lots of Love

Steve