state machines caveat

[ozimmer]

I have been using the state machine design pattern in programs for a
while. In this technique, it is a common practice to define boolean
switches to trigger actions in the next iteration of the machine (eg.
"TurnLaserON", "Quit", "Compute", "SetAlarm1"...). Thus, the boundary
between data and processing is easily trespassed.

This sounds to me like a possible source of errors, that should be
limited by some design rule of thumb. I tend to believe that boolean
triggers in state machines should be looked at with the same precautions
as a "GOTO" control structure.

Do you have any experience or theoretical frame to enlighten these
considerations ?


oz

[LesHammer]

> This sounds to me like a possible source of errors, that should be
> limited by some design rule of thumb. I tend to believe that boolean
> triggers in state machines should be looked at with the same precautions
> as a "GOTO" control structure.

The big problem with a GOTO is that once you get there it is hard to tell
where you "Came From." Boolean switches don't suffer the same problem, even if
booleans can also be used as data. You could always name your booleans to indicate
that it is a switch, rather than data, if that helps.

Les.Hammer@CompleteTest.com

[wiebe@CARYA]

Hi,

I always prefer a state machine with a state buffer. This means, every state
can, potentially, call several other states. In practice, there is a shift
register with an array of strings in it. The first string is called, and
removed. Every state can modify the buffer, so:

+ states can be put before, after or between the buffer
+ states can be removed
+ states can be filtered, sorted etc.
+ buffered states can be copied

This makes programming with state machines a lot easier. You can simply make
a state TurnLaserON, and in the calling state(s) diside what the state after
TurnLaserON has to be. This makes the program a lot clearer.

Some design rules I use (mainlly because if I don't use them, there is no
way of documenting the program):

+ states may only put states before the buffer (I call them sub states)
+ buffered states cannot be removed in a state

Using these rules, I can put the entire program on paper, without any
problem.

Still, I have to transfere information between states. This 'information'
can be a shift register with a bundle, indicators on the front panel (not
visible to the end user), a GLI, buffers, ini file reference, or whatever. I
have never found any big advantage or disadvantage for eny of them, but I
prefer indicators (mixed with buffers when convenient), because they are the
fastest to use (for me), and easiest to debug (IMO).

Regards,

Wiebe.

"O. Zimmermann" wrote in message
news:3E6CB966.7010503@isn.in2p3.fr...
>
> I have been using the state machine design pattern in programs for a
> while. In this technique, it is a common practice to define boolean
> switches to trigger actions in the next iteration of the machine (eg.
> "TurnLaserON", "Quit", "Compute", "SetAlarm1"...). Thus, the boundary
> between data and processing is easily trespassed.
>
> This sounds to me like a possible source of errors, that should be
> limited by some design rule of thumb. I tend to believe that boolean
> triggers in state machines should be looked at with the same precautions
> as a "GOTO" control structure.
>
> Do you have any experience or theoretical frame to enlighten these
> considerations ?
>
>
> oz
>

[mikeporter]

I'm not sure what you mean by "the boundary between data and processing" but state machines can be poorly designed and -- more importantly -- misapplied. The way I know where the boolean input came from is that I (or the operator) pushed the button.

Which is the point, the rigth place to use state machines is generally in user interfaces. The Other good place s if you are implementing a low-level instrument driver of communications protocol. In those cases vendors will sometimes document their interface in terms of a state machine, so implementing it inthat way makes it easier on you, and whoever is coming along after you to maintain the code.

Finally, don't forget that a state machine needs to be subjected to the same systematic design that you should be
subjecting the rest of your application to. In general, it is a bad idea to have a single event (key press, input, whatever) trigger off a whole series of state changes. There are exceptions, but they are rare.

Mike...

[urs boegli]

oz,
I'm using state machines for years in sof and hardware - it's a great thing.

One of the problems not mentioned yet:

Let's imagine you have 3 booleans A,B,C as states.
You program it with the help of some cases like: if A then.....
You think at the moment if A is true C is never true. But one day when the whole system is not
warmed-up or one part is dameaged you will get Atrue and Ctrue and your program might hang-up,
destroy your lab....

Rules:
Every (EVERY) possible state needs an output to another state (at least 'start')
Every state has defined action (at least 'no operation')

Good Luck
Urs




"O. Zimmermann" schrieb:

> I have been using the state machine design pattern in programs for a
> while. In this technique, it is a common practice to define b
oolean
> switches to trigger actions in the next iteration of the machine (eg.
> "TurnLaserON", "Quit", "Compute", "SetAlarm1"...). Thus, the boundary
> between data and processing is easily trespassed.
>
> This sounds to me like a possible source of errors, that should be
> limited by some design rule of thumb. I tend to believe that boolean
> triggers in state machines should be looked at with the same precautions
> as a "GOTO" control structure.
>
> Do you have any experience or theoretical frame to enlighten these
> considerations ?
>
> oz