Learn Automation with MINATA #61: Machine States — Stop, Run, Fault and the Conditions Between Them
Machine States: Stop, Run, Fault and the Conditions Between Them
A machine does not simply "run" or "stop" according to one bit. Before writing the logic, build a state model so the operator, the PLC and the HMI all understand the same thing about what the machine is doing. A clear model at the start saves a great deal of patched-on logic later.
Why one Run bit is not enough
A real machine passes through several states: idle, ready, running, stopping under control, emergency stopped and faulted. Collapsing all of that into "running or stopped" throws away the information the operator needs and makes the logic hard to test. Each state carries its own meaning about what the machine may do and what it should display.
The state table is the design
Draw the state table before programming. For each state, define which commands are valid, which conditions permit it, what happens on entry, and what makes it exit.
| State | Valid commands | Permissive condition | Exits when |
|---|
| Idle | — | Supply and safety healthy | A preparation command arrives |
| Ready | Start | Guards closed, no fault | A valid Start is pressed |
| Run | Stop | Running conditions maintained | Stop, cycle complete, or a fault |
| Stopping | — | — | Safely stopped |
| Fault | Reset | The cause has been dealt with | Reset plus confirmation |
A transition needs a reason
Every transition needs an entry condition, an exit condition and a safe action. A Start command while the guard door is still open must not produce Run. Instead it leaves a blocking reason for the HMI to explain to the operator — "cannot start: door open" — rather than silently doing nothing.
A worked engineering situation
On a packing station, the PLC holds a single state variable and a list of permissives. When the operator presses Start while the guard is still open, the machine stays in Ready and the HMI displays the blocking reason. Only when the guard is closed and there is no fault does Start move it to Run. The fault state requires a deliberate reset before returning to Ready.
The list of states, the conditions and the actions all follow the risk assessment and the requirements of the real machine.
Common mistakes
- Using one Run bit for everything, and losing the state information.
- Transitions with no clear entry and exit conditions.
- Start blocked, but no reason left behind for the HMI.
- Mixing the operational stop and the emergency stop in the same branch.
- Letting a fault clear itself back to Ready with no deliberate reset.
Machine state checklist
- [ ] A state table exists, with valid commands and permissive conditions.
- [ ] Every transition has an entry condition, an exit condition and a safe action.
- [ ] A blocked command leaves a reason the HMI can display.
- [ ] The operational stop and the emergency stop are separate.
- [ ] A fault needs a deliberate reset before the machine can run again.
A clear state model is the foundation of logic that can be tested and an HMI that can explain itself. #62 standardises the model against PackML, to make line integration easier.
Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation
Previous — #60: The automation project roadmap: https://minatavn.com/en/blog/automation-60-automation-project-roadmap
Next — #62: PackML machine states: https://minatavn.com/en/blog/automation-62-packml-machine-states
View all MINATA technical articles