State machines — ST course

How sequences turn into spaghetti

A mixing tank in a sauce kitchen runs the same cycle all day: open the inlet until the high-level switch makes, run the agitator for 90 seconds, open the drain until the tank is empty, start again. Three steps. Every engineer's first attempt at it looks something like this:

IF Start AND NOT Filling AND NOT Mixing AND NOT Draining THEN
    Filling := TRUE;
END_IF;
IF Filling AND LevelHigh THEN
    Filling := FALSE;
    Mixing := TRUE;
END_IF;
MixTimer(IN := Mixing, PT := T#90s);
IF MixTimer.Q THEN
    Mixing := FALSE;
    Draining := TRUE;
END_IF;
IF Draining AND TankEmpty THEN
    Draining := FALSE;
END_IF;
InletValve := Filling;
Agitator   := Mixing;
DrainValve := Draining;

It works on the first day. Then the requests come. Add a stop button that finishes the batch. Add an abort that closes everything now. Add a fill timeout in case the supply valve is shut. Add a heating step for one recipe only. Each change adds a flag and a few more AND NOTs, and each flag can be TRUE or FALSE independently. Three flags give eight combinations, of which four are legal. Six flags give 64. Sooner or later a power dip or an abort leaves Mixing and Draining both TRUE, the program happily runs the agitator with the drain open, and nobody can tell from the online view which step the machine thinks it is in.

The fix is to stop describing the sequence with independent flags and describe it with one variable that can only hold one value: the current state.

One state variable, one CASE

A state machine has three parts:

a state variable — usually an INT — that says which step the machine is in;
a CASE on that variable, with one branch per state, containing only the conditions for leaving that state;
outputs derived from the state, assigned once, after the CASE.

PROGRAM Main
VAR
    Start      : BOOL;   (* input: start push button *)
    LevelHigh  : BOOL;   (* input: high-level switch *)
    TankEmpty  : BOOL;   (* input: low-level switch, TRUE = empty *)
    State      : INT;    (* 0 = idle, 10 = filling, 20 = draining *)
    InletValve : BOOL;   (* output *)
    DrainValve : BOOL;   (* output *)
END_VAR

CASE State OF
    0:  (* IDLE *)
        IF Start THEN
            State := 10;
        END_IF;

    10: (* FILLING *)
        IF LevelHigh THEN
            State := 20;
        END_IF;

    20: (* DRAINING *)
        IF TankEmpty THEN
            State := 0;
        END_IF;
END_CASE;

InletValve := State = 10;
DrainValve := State = 20;

END_PROGRAM

Live example — open this page with JavaScript to run and edit it. Inputs you can drive: Start, LevelHigh, TankEmpty.

Press Start and release it: the state goes to 10 and the inlet opens. Turn LevelHigh on: state 20, inlet closed, drain open. Turn LevelHigh off and TankEmpty on: back to 0. The tank cannot be filling and draining at once, because State cannot be 10 and 20 at once. The illegal combinations are gone, not guarded against.

Two conventions are worth adopting from day one. Number states in steps of ten, so you can insert a heating step as 15 next year without renumbering everything. And keep the outputs out of the CASE. InletValve := State = 10; is assigned on every scan, so it can never be left latched by a branch that stopped running — the missing-ELSE trap from chapter 5 cannot happen. When an output is on in several states, say so: Agitator := (State = 20) OR (State = 25);. One line per output, readable as a sentence, is worth more than any amount of cleverness inside the branches.

Transitions with conditions

Each branch holds the transitions out of its own state, and nothing else. A transition is an IF that assigns a new value to State. Because the CASE executes exactly one branch per scan, the machine moves at most one state per scan — a fact that surprises people the first time.

Predict: Start and LevelHigh are both already TRUE when the program starts in state 0. What is State after one scan?

PROGRAM Main
VAR
    Start     : BOOL := TRUE;
    LevelHigh : BOOL := TRUE;
    State     : INT;
END_VAR

CASE State OF
    0:  IF Start THEN State := 10; END_IF;
    10: IF LevelHigh THEN State := 20; END_IF;
END_CASE;

END_PROGRAM

20 — both transitions are true, so it passes through 10 on the way
10 — the CASE picks one branch per scan, using the value State had when the CASE started
0 — a transition takes effect only on the next scan

Show the answer

10 — the CASE picks one branch per scan, using the value State had when the CASE started

CASE evaluates State once, selects the branch for 0, and runs it. That branch sets State to 10, and the CASE is finished. The branch for 10 runs on the next scan, where it moves to 20. One state per scan is a feature: every state is guaranteed to exist for at least one scan, so its outputs and entry actions always get a chance to run. On a 10 ms task nobody will notice the extra scan.

When a state has more than one way out, order the IFs by priority and use ELSIF, so exactly one transition fires. Put the safety-related exit first:

10: (* FILLING *)
    IF StateTimer.ET > T#60s THEN
        State := 90;            (* fill timeout: supply valve shut? *)
    ELSIF LevelHigh THEN
        State := 20;
    END_IF;

Write the condition so that it reads like the specification. "Leave filling when the level is high" is IF LevelHigh. If a condition needs a comment to explain it, it probably needs a named variable instead, calculated above the CASE: FillComplete := LevelHigh AND LevelHighConfirm.Q;.

Entry actions and the first scan in a state

Some things should happen once, when a state is entered: add one to the batch counter as filling starts, store the start weight, write a message to the batch log. Doing them "while in the state" repeats them every scan. You need a flag that is TRUE for exactly one scan after every transition:

PROGRAM Main
VAR
    Start      : BOOL;
    LevelHigh  : BOOL;
    TankEmpty  : BOOL;
    State      : INT;
    LastState  : INT := -1;   (* differs from State on the very first scan *)
    StateEntry : BOOL;        (* TRUE for one scan after every transition *)
    Batches    : DINT;
    InletValve : BOOL;
    DrainValve : BOOL;
END_VAR

StateEntry := State <> LastState;
LastState  := State;

CASE State OF
    0:  IF Start THEN State := 10; END_IF;

    10: IF StateEntry THEN
            Batches := Batches + 1;   (* entry action: once per batch *)
        END_IF;
        IF LevelHigh THEN State := 20; END_IF;

    20: IF TankEmpty THEN State := 0; END_IF;
END_CASE;

InletValve := State = 10;
DrainValve := State = 20;

END_PROGRAM

Live example — open this page with JavaScript to run and edit it. Inputs you can drive: Start, LevelHigh, TankEmpty.

The two lines at the top compare the state with last scan's. Any transition, from anywhere, makes StateEntry TRUE on the following scan, in the new state's branch. Run a few batches and watch Batches go up by exactly one each time, however long the fill takes. Initialising LastState to −1 makes the first scan after a restart an entry into state 0, so state 0's entry actions run at power-up too — a good place to reset things.

A timer per state

Most sequences need time: mix for 90 s, wait 2 s for a valve to settle, give up filling after 60 s. You could declare a timer for each of those, but there is a neater pattern. A single TON that restarts on every state entry measures how long the machine has been in its current state:

StateTimer(IN := NOT StateEntry, PT := T#24h);

On the entry scan IN is FALSE, so the timer resets; from the next scan it runs, and StateTimer.ET is the state time. Every branch can compare against it: IF StateTimer.ET >= T#90s THEN to finish mixing, IF StateTimer.ET > T#60s THEN for the fill timeout. The PT is simply longer than any state will ever last. The HMI can show StateTimer.ET next to the step name, which operators love: "Mixing, 47 s".

Notice where the call is: at the top, outside the CASE, on every scan. The rule from chapter 9 — call every timer on every scan — is broken more often inside state machines than anywhere else, because putting a timer in the branch that uses it looks so tidy.

Predict: The mixing timer is called inside the mixing branch with IN := TRUE. The tank runs two batches. The first batch mixes for 6 scans. How many scans does the second batch mix?

PROGRAM Main
VAR
    State     : INT;
    Batch     : INT;
    MixScans  : INT;
    MixTimer  : TON;
    FirstMix  : INT;
    SecondMix : INT;
END_VAR

CASE State OF
    0:  Batch := Batch + 1;
        MixScans := 0;
        State := 10;

    10: MixScans := MixScans + 1;
        MixTimer(IN := TRUE, PT := T#500ms);   (* called only in this state *)
        IF MixTimer.Q THEN State := 20; END_IF;

    20: IF Batch = 1 THEN FirstMix := MixScans; END_IF;
        IF Batch = 2 THEN SecondMix := MixScans; END_IF;
        State := 0;
END_CASE;

END_PROGRAM

6 — every batch gets the same mixing time
1 — the timer is still done from the first batch
0 — the second batch skips the mixing state entirely
It never finishes — the timer cannot restart

Show the answer

1 — the timer is still done from the first batch

In states 20 and 0 the timer is not called, so it never sees IN go FALSE. When the second batch enters state 10, the call still has IN = TRUE with no new rising edge, so Q is still TRUE from the first batch and the transition fires on the first scan. On the real tank the second batch of sauce gets one scan of mixing. Use the shared StateTimer called above the CASE, or call a dedicated timer every scan with IN := State = 10.

Fill, mix, drain

Here is the complete tank sequence, with the entry flag, the state timer and a 3 s mix (90 s on the real tank, shortened so you can watch it):

PROGRAM Main
VAR
    Start      : BOOL;
    LevelHigh  : BOOL;
    TankEmpty  : BOOL;
    State      : INT;          (* 0 idle, 10 filling, 20 mixing, 30 draining *)
    LastState  : INT := -1;
    StateEntry : BOOL;
    StateTimer : TON;
    InletValve : BOOL;
    Agitator   : BOOL;
    DrainValve : BOOL;
END_VAR

StateEntry := State <> LastState;
LastState  := State;
StateTimer(IN := NOT StateEntry, PT := T#24h);

CASE State OF
    0:  (* IDLE *)
        IF Start AND TankEmpty THEN State := 10; END_IF;

    10: (* FILLING *)
        IF LevelHigh THEN State := 20; END_IF;

    20: (* MIXING *)
        IF StateTimer.ET >= T#3s THEN State := 30; END_IF;

    30: (* DRAINING *)
        IF TankEmpty THEN State := 0; END_IF;
END_CASE;

InletValve := State = 10;
Agitator   := State = 20;
DrainValve := State = 30;

END_PROGRAM

Live example — open this page with JavaScript to run and edit it. Inputs you can drive: Start, LevelHigh, TankEmpty.

Run a batch by hand: TankEmpty on, Start on and off, then TankEmpty off (the tank is filling), LevelHigh on. The agitator runs for 3 s by itself and the drain opens. Turn LevelHigh off and TankEmpty on to finish. Notice that idle only starts a batch when the tank is empty. Every transition condition is also a check that the machine is where the program thinks it is.

Challenge: Press cycle with a dwell

A hydraulic press bonds a laminate. One cycle: the ram moves down until BottomLimit, holds the pressure for 2 s, then returns up until TopLimit. Use these states:

0 — idle. Start begins a cycle (go to 10).
10 — pressing down. PressDown is on. At BottomLimit, go to 20.
20 — dwell. Both valves off; the pump holds pressure. After 2 s in this state, go to 30.
30 — returning. PressUp is on. At TopLimit, go to 0.

The starter skips the dwell: it goes from pressing straight to returning, and the laminate never bonds.

PROGRAM Main
VAR
    Start       : BOOL;   (* input: two-hand start, already validated *)
    BottomLimit : BOOL;   (* input *)
    TopLimit    : BOOL;   (* input *)
    State       : INT;    (* output: step number *)
    LastState   : INT := -1;
    StateEntry  : BOOL;
    StateTimer  : TON;
    PressDown   : BOOL;   (* output: valve solenoid *)
    PressUp     : BOOL;   (* output: valve solenoid *)
END_VAR

StateEntry := State <> LastState;
LastState  := State;
StateTimer(IN := NOT StateEntry, PT := T#24h);

CASE State OF
    0:  IF Start THEN State := 10; END_IF;
    10: IF BottomLimit THEN State := 30; END_IF;
    30: IF TopLimit THEN State := 0; END_IF;
END_CASE;

PressDown := State = 10;
PressUp   := State = 30;

END_PROGRAM

Case	Plant sets	Program must give
Idle at the top	Start = FALSE, BottomLimit = FALSE, TopLimit = TRUE	State = 0, PressDown = FALSE, PressUp = FALSE
Start pressed	Start = TRUE	State = 10, PressDown = TRUE
Ram travelling down	Start = FALSE, TopLimit = FALSE	State = 10, PressDown = TRUE, PressUp = FALSE
Bottom reached	BottomLimit = TRUE	State = 20, PressDown = FALSE, PressUp = FALSE
Dwell, 1.5 s	—	State = 20, PressUp = FALSE
Dwell, 2.5 s	—	State = 30, PressUp = TRUE
Ram leaves the bottom	BottomLimit = FALSE	State = 30, PressUp = TRUE
Top reached	TopLimit = TRUE	State = 0, PressUp = FALSE

Hints

The dwell is its own state, 20, with both outputs off — and since the outputs are derived from State, it needs no output code at all.
In state 10, BottomLimit should lead to 20 instead of 30.
In state 20 the only transition is time: IF StateTimer.ET >= T#2s THEN State := 30. The state timer is already called every scan above the CASE.

Show a solution

PROGRAM Main
VAR
    Start       : BOOL;
    BottomLimit : BOOL;
    TopLimit    : BOOL;
    State       : INT;
    LastState   : INT := -1;
    StateEntry  : BOOL;
    StateTimer  : TON;
    PressDown   : BOOL;
    PressUp     : BOOL;
END_VAR

StateEntry := State <> LastState;
LastState  := State;
StateTimer(IN := NOT StateEntry, PT := T#24h);

CASE State OF
    0:  IF Start THEN State := 10; END_IF;
    10: IF BottomLimit THEN State := 20; END_IF;
    20: IF StateTimer.ET >= T#2s THEN State := 30; END_IF;
    30: IF TopLimit THEN State := 0; END_IF;
END_CASE;

PressDown := State = 10;
PressUp   := State = 30;

END_PROGRAM

Stop, abort and fault states

A sequence that can only run forwards is half a sequence. Real machines need three ways off the happy path, and they are not the same thing:

Stop — finish what you are doing, then rest. The cycle-stop button on a palletiser completes the current layer. Usually this is just an extra condition in idle: don't start another cycle while CycleStop is set.
Abort — leave now and make everything safe. A global transition, written before the CASE, that sends any running state straight to idle (or to a dedicated aborting state if things must be done in order: close the inlet, then open the vent). Because the outputs are derived from the state, State := 0 switches them all off on the same scan.
Fault — something went wrong that a person must look at. The sequence moves to a fault state, typically 90 or 900, that holds the outputs safe and stays there until a deliberate reset. Step timeouts are the most useful fault source you will ever write: every state that waits for the machine should also give up after a reasonable time.

(* Global transitions: evaluated before the CASE, highest priority first *)
IF Abort AND State > 0 AND State < 90 THEN
    State := 0;
END_IF;

Emergency stops are not on that list on purpose. The e-stop circuit removes power through safety relays or a safety PLC, independently of this program. The sequence must notice the e-stop — usually by aborting — but it is never what makes the machine safe.

Challenge: Fill sequence with abort and timeout

Extend the tank sequence with an abort and a fill timeout. Use these states:

0 — idle. Start begins a batch (go to 10).
10 — filling. InletValve open. LevelHigh → 20. If the tank has been filling for more than 5 s, go to fault, 90.
20 — draining. DrainValve open. TankEmpty → 0.
90 — fault. All valves closed, Alarm on. Only Reset leaves it (→ 0).
Abort sends states 10 and 20 straight to 0.

The starter runs the normal cycle but has no timeout and ignores Abort.

PROGRAM Main
VAR
    Start      : BOOL;   (* input *)
    Abort      : BOOL;   (* input *)
    Reset      : BOOL;   (* input *)
    LevelHigh  : BOOL;   (* input *)
    TankEmpty  : BOOL;   (* input *)
    State      : INT;    (* output: step number *)
    LastState  : INT := -1;
    StateEntry : BOOL;
    StateTimer : TON;
    InletValve : BOOL;   (* output *)
    DrainValve : BOOL;   (* output *)
    Alarm      : BOOL;   (* output *)
END_VAR

StateEntry := State <> LastState;
LastState  := State;
StateTimer(IN := NOT StateEntry, PT := T#24h);

CASE State OF
    0:  IF Start THEN State := 10; END_IF;
    10: IF LevelHigh THEN State := 20; END_IF;
    20: IF TankEmpty THEN State := 0; END_IF;
END_CASE;

InletValve := State = 10;
DrainValve := State = 20;
Alarm      := State = 90;

END_PROGRAM

Case	Plant sets	Program must give
Idle, tank empty	Start = FALSE, Abort = FALSE, Reset = FALSE, LevelHigh = FALSE, TankEmpty = TRUE	State = 0, InletValve = FALSE, Alarm = FALSE
Start	Start = TRUE	State = 10, InletValve = TRUE
Filling for 2 s	Start = FALSE, TankEmpty = FALSE	State = 10, InletValve = TRUE, Alarm = FALSE
Level high	LevelHigh = TRUE	State = 20, InletValve = FALSE, DrainValve = TRUE
Draining	LevelHigh = FALSE	State = 20, DrainValve = TRUE
Abort while draining	Abort = TRUE	State = 0, DrainValve = FALSE
Abort released, new batch	Abort = FALSE, Start = TRUE	State = 10, InletValve = TRUE
Supply shut: no level after 5.5 s	Start = FALSE	State = 90, InletValve = FALSE, Alarm = TRUE
Level arrives late: fault holds	LevelHigh = TRUE	State = 90, Alarm = TRUE, DrainValve = FALSE
Reset	LevelHigh = FALSE, Reset = TRUE	State = 0, Alarm = FALSE

Hints

The abort is a global transition: an IF before the CASE that moves 10 or 20 to 0, so it works whatever state the sequence is in.
The timeout lives in state 10 and uses the state timer: StateTimer.ET > T#5s. Check it before LevelHigh with IF … ELSIF.
State 90 needs a branch of its own whose only way out is Reset. The outputs need no change — Alarm is already derived from State = 90.

Show a solution

PROGRAM Main
VAR
    Start      : BOOL;
    Abort      : BOOL;
    Reset      : BOOL;
    LevelHigh  : BOOL;
    TankEmpty  : BOOL;
    State      : INT;
    LastState  : INT := -1;
    StateEntry : BOOL;
    StateTimer : TON;
    InletValve : BOOL;
    DrainValve : BOOL;
    Alarm      : BOOL;
END_VAR

StateEntry := State <> LastState;
LastState  := State;
StateTimer(IN := NOT StateEntry, PT := T#24h);

IF Abort AND (State = 10 OR State = 20) THEN
    State := 0;
END_IF;

CASE State OF
    0:  IF Start AND NOT Abort THEN State := 10; END_IF;
    10: IF StateTimer.ET > T#5s THEN
            State := 90;
        ELSIF LevelHigh THEN
            State := 20;
        END_IF;
    20: IF TankEmpty THEN State := 0; END_IF;
    90: IF Reset THEN State := 0; END_IF;
END_CASE;

InletValve := State = 10;
DrainValve := State = 20;
Alarm      := State = 90;

END_PROGRAM

Naming the states

State = 20 is fine for three states and awful for fifteen. Somebody reading branch 40 at 3 a.m. should not need a lookup table. The traditional fix is named constants:

VAR CONSTANT
    ST_IDLE     : INT := 0;
    ST_FILLING  : INT := 10;
    ST_MIXING   : INT := 20;
    ST_DRAINING : INT := 30;
    ST_FAULT    : INT := 90;
END_VAR

CASE State OF
    ST_IDLE:    IF Start THEN State := ST_FILLING; END_IF;
    ST_FILLING: IF LevelHigh THEN State := ST_MIXING; END_IF;
    (* ... *)
END_CASE;

CODESYS, TwinCAT and the engine on these pages all accept constants as CASE labels. The live examples above use numbers with comments only so the jumps are easy to follow; on a real controller, write the constants version — it is the more maintainable one.

Better still is an enumerated type, which makes the state variable unable to hold anything but a named state, and shows the name, not the number, in the online view:

TYPE E_TankStep :
(
    IDLE     := 0,
    FILLING  := 10,
    DRAINING := 20
);
END_TYPE

PROGRAM Main
VAR
    Start      : BOOL;
    LevelHigh  : BOOL;
    TankEmpty  : BOOL;
    Step       : E_TankStep;
    InletValve : BOOL;
    DrainValve : BOOL;
END_VAR

CASE Step OF
    IDLE:     IF Start THEN Step := FILLING; END_IF;
    FILLING:  IF LevelHigh THEN Step := DRAINING; END_IF;
    DRAINING: IF TankEmpty THEN Step := IDLE; END_IF;
END_CASE;

InletValve := Step = FILLING;
DrainValve := Step = DRAINING;

END_PROGRAM

Live example — open this page with JavaScript to run and edit it. Inputs you can drive: Start, LevelHigh, TankEmpty.

Run it and the watch table reads FILLING, not 10. The explicit values keep the step numbers for the HMI and for anyone comparing with the old documentation. Chapter 15 covers ENUMs properly, including how vendors scope the names (E_TankStep.FILLING in CODESYS and TwinCAT when the type carries the qualified_only attribute).

When a sequence grows past a dozen states with branches running in parallel, the CASE starts to strain, and IEC 61131-3 has a graphical language built for exactly this: Sequential Function Chart, sold as S7-GRAPH in TIA Portal and as SFC in Studio 5000 and CODESYS. The ideas — steps, transitions, one active step per sequence, actions on entry — are the ones you have just written by hand. Try them in the SFC lab.

Next: many values at once

Everything so far has handled one tank, one press, one conveyor. A real plant has eight identical zones, twenty temperature readings and a recipe with forty parameters, and writing each one out by name stops scaling quickly. Chapter 13 introduces arrays and FOR loops: storing many values under one name and processing them all in a single scan.

How sequences turn into spaghetti

One state variable, one CASE

Transitions with conditions

Entry actions and the first scan in a state

A timer per state

Fill, mix, drain

Stop, abort and fault states

Naming the states

Next: many values at once

Practise this chapter