Machine Design #52: State Machines — Do Not Put the Whole Machine in One StepNo Variable
Many PLC programs contain a variable called StepNo. It may begin as a simple sequence and slowly become the place where mode, output commands, timers, faults, retries, HMI behavior, and restart decisions all live.
StepNo is not the enemy. The missing contract is.
Mode defines how the machine is being used. State defines what is true. Step defines work inside a state. Transition defines how and why behavior changes.
1. StepNo is not wrong; an undefined contract is
A sequential number is useful when its scope, entry condition, exit condition, outputs, timeout, fault behavior, and restart meaning are explicit. It becomes fragile when StepNo=40 means different things in automatic, manual, recovery, and maintenance modes.
2. Separate mode, state, and step
Mode
The operating context: automatic, manual, setup, maintenance, simulation, recovery, or safe stop. Mode determines which commands and transitions are permitted.
State
The machine condition: idle, ready, loading, processing, unloading, held, faulted, complete, or waiting. A state should be observable and have stable meaning.
Step
A bounded activity within a state: extend cylinder, wait for feedback, transfer carrier, verify result, or save data. Steps should not silently change the machine’s mode or ownership.
3. Six questions every state must answer
What does the state mean? What must be true on entry? What outputs are owned? What activity runs while inside? Which events can leave it? What happens on timeout, invalid event, stop, fault, and restart?
If the team cannot answer these questions, the state is a label, not a design contract.
4. Invariants are more important than state names
An invariant is a condition that must remain true: a clamp cannot open while a part is unsupported; a robot cannot enter a zone while a person has access; a recipe cannot run with incompatible tooling; a complete result belongs to one transaction.
Write invariants across states and test them during normal, abnormal, and restart behavior. A descriptive state name does not protect an invariant.
5. A transition is a contract
Define source and target, trigger, guard, action, priority, and invalid-event behavior. Example: from Receiving to Processing when the carrier ID is accepted, tooling is compatible, guard is closed, and the receiving sensor is valid. The transition must say what happens if the signal is stale or the timeout expires.
6. Hidden priority causes hard-to-find faults
Two transitions may be true at the same time: complete and fault, stop and reset, abort and retry. Make priority explicit and log which transition won. Do not rely on PLC scan order or the order of IF statements as an undocumented policy.
7. Entry, do, and exit actions
Entry action
Initialize timers, claim outputs, capture transaction, or create a trace record. Entry must be safe if the state is reached after a restart.
Do activity
Execute the bounded work and monitor feedback, timeout, quality, and faults. Avoid repeating a one-time command on every scan unless the design requires it.
Exit action
Release ownership, save result, clear temporary commands, and leave the machine in a defined condition. Do not release an actuator while another state assumes it is still held.
8. Hierarchy reduces state explosion
Group common behavior into superstates such as Safe, Ready, Executing, and Recovering. Define which transitions are inherited and which are overridden. Hierarchy should reduce duplication without hiding an important safety or recovery condition.
9. Concurrency needs coordination
Two sequences can run in parallel: material transfer and inspection, or robot motion and fixture preparation. Define shared resources, ownership, synchronization, interlocks, cancellation, and completion. A global StepNo cannot describe two independently progressing sequences safely.
10. Mode change is a conditional transition
Changing from automatic to manual, or from production to maintenance, needs a safe boundary, output handling, permission, and reconciliation. Define whether work in progress is held, cancelled, completed, or rejected. Do not change a mode by writing one bit while actuators remain under another mode’s ownership.
11. Stop, hold, abort, fault, and complete differ
Stop requests a controlled halt. Hold pauses work while preserving a valid context. Abort cancels a transaction and defines what happens to the part. Fault indicates abnormal behavior requiring diagnosis or recovery. Complete means the defined result and evidence are available. The HMI and interface contract must use the same meanings.
12. Startup and restart reconcile logic with physics
After power loss, software state may say Processing while the carrier is absent or an actuator is halfway. On startup, inspect physical sensors, drives, tooling, recipe, safety, and transaction ID. Enter a reconciliation or safe recovery state when software and physical state disagree.
13. State observability is a requirement
Expose current mode, state, step, transition reason, owner, timer, transaction, fault, recovery instruction, and last valid event. A maintenance engineer should not need to attach a debugger to know why the machine is waiting.
14. IEC 61131-3 helps implementation, not architecture
Structured Text, Sequential Function Chart, and other IEC 61131-3 languages provide implementation tools. They do not decide the correct states, invariants, ownership, or recovery. Architecture comes from the machine requirements and operating risks.
15. Use IEC 61512/ISA-88 and PackML deliberately
ISA-88 and PackML can give teams a shared vocabulary for modes and states. They are reference patterns, not permission to copy a template without mapping the actual machine, product, interface, safety, and maintenance needs.
16. Hypothetical pick-transfer-place sequence
Behavior hierarchy
Ready → Pick → Transfer → Place → Verify → Complete, with Hold, Abort, Fault, and Recover available according to conditions.
Invariant
The robot owns the carrier only after pick confirmation; the destination fixture is not released until place verification; the recipe ID remains attached to the transaction.
Example transition
Transfer → Place requires robot in destination zone, fixture ready, carrier ID valid, and no safety or communication fault.
Fault case
If position feedback is missing, enter a controlled fault and preserve the carrier identity. Do not jump to the next StepNo.
Restart case
On restart, reconcile robot position, gripper state, carrier presence, recipe, and transaction before selecting a recovery path.
17. Verification matrix
Test each state and transition for entry, normal activity, timeout, invalid event, stop, hold, abort, fault, recovery, mode change, power loss, reconnect, product variant, and operator role. Link the case to an invariant and evidence.
18. State-machine review checklist
- [ ] Mode, state, and step have separate meanings.
- [ ] Every state has entry, activity, exit, timeout, fault, and restart behavior.
- [ ] Invariants are explicit and tested.
- [ ] Transitions define trigger, guard, action, priority, and invalid event.
- [ ] Output ownership is unambiguous.
- [ ] Hierarchy and concurrency do not hide safety or recovery.
- [ ] Stop, hold, abort, fault, and complete are distinct.
- [ ] Mode change has a safe boundary and reconciliation.
- [ ] Software state is reconciled with physical state after restart.
- [ ] Observability exposes why the machine is waiting or faulted.
- [ ] Verification covers normal, abnormal, restart, and interface composition.
Conclusion
A state machine makes behavior reviewable when mode, state, step, transition, invariant, ownership, and recovery are explicit. StepNo can remain as an implementation detail, but it should not be the only contract the machine has.
References
- IEC 61131-3:2025 — Programmable controllers: https://webstore.iec.ch/en/publication/68532
- IEC 61512 — Batch control: https://webstore.iec.ch/en/publication/6030
View all MINATA technical articles