Why HMI Command and PLC Status Should Be Separate
Pressing Start on an HMI does not mean the machine is actually running. A request and a verified machine state are different facts.
Command is a request; status is the result
An HMI may write M100 Start_CMD, while the PLC exposes M200 Run_STS only after permissives and interlocks are satisfied. If a fault blocks the run, the command can exist without the status becoming true.
One shared bit can make the screen lie
If the same bit drives both the button and the running lamp, the HMI may show “running” the moment the operator presses Start even though the output is blocked. Network delay and controller restart make this ambiguity worse.
A practical ownership pattern
| Role | Example | Owner |
|---|---|---|
| Run request | Start_CMD | HMI → PLC |
| Stop request | Stop_CMD | HMI → PLC |
| Running state | Run_STS | PLC → HMI |
| Fault state | Fault_STS | PLC → HMI |
Momentary commands may need pulse or acknowledgement
Use edge processing or a command/acknowledgement pattern when a momentary action must not repeat because of a stuck HMI bit or communications delay. The HMI should request action; the PLC should own final machine state.