Why Your HMI Should Never Merge Mode and State Into One Field
Mode is who may command the equipment; state is what it is doing. SEMI E30's control state model splits them — here is how to split the HMI to match.
Two in the morning, the equipment is sitting still, and the HMI says "Stopped." Nothing on the screen says whether an operator stopped it, whether it is in LOCAL and quietly refusing host commands, whether an interlock is holding it, or whether comms dropped thirty minutes ago and the last good value is frozen on the display. That is where the radio call starts, and where twenty minutes go.
This is not a missing-data problem. It is a collapsed-axis problem. Mode answers "who is allowed to command this," state answers "what is it actually doing," and the two are independent — they only start earning their space when the combination gets strange. SEMI E30 (GEM) nails the distinction down as two separate state models: the control state model is the mode axis, the processing state model is the state axis. When the host-side code already tracks both and the HMI merges them into one field, the screen is throwing away information it already has.
The mode axis is already drawn for you
The picture above is the whole GEM control state model. OFFLINE contains EQUIPMENT OFFLINE, ATTEMPT ONLINE and HOST OFFLINE; ONLINE contains LOCAL and REMOTE. One rule separates the two that matter: LOCAL answers host queries but refuses remote commands, while REMOTE accepts them. Half of every "why won't START work from the host" is not an alarm problem — it is this one field never making it onto a screen.
The host asks to go online with S1F17 and gets S1F18 (ONLACK) back; the other direction is S1F15 / S1F16. ONLACK handling is where host developers most often step on a mine. Zero means accepted, but not every non-zero value means "the equipment isn't answering." Send S1F17 to equipment that is already online and you get a distinct already-online response — and I have seen that lumped in with failure more than once, producing a retry loop against a tool that was online the entire time. Refused and already-online are different events. Branch on the value instead of testing it against zero.
There are really three axes, not two. The communication state model is separate again: DISABLED / ENABLED, with NOT COMMUNICATING and COMMUNICATING inside ENABLED. An established HSMS session, GEM being COMMUNICATING, and the control state being ONLINE are three different facts. The socket can be up while S1F13 / S1F14 has not completed, so you are not COMMUNICATING; you can be COMMUNICATING and still get commands refused because the tool is in LOCAL. A single "comms OK" lamp on the HMI mashes all three into one indicator, and a mashed indicator fails exactly when things are abnormal.
The state axis works the opposite way. E30 does not hand you the values — it requires the equipment to define its own processing state model and document it in the GEM manual. That is why Idle / Setup / Ready / Executing differ from tool to tool, and why a host that hardcodes those strings breaks on the next tool. SEMI E10 then overlaps as yet another axis: the six basic states used for utilisation accounting (Non-Scheduled, Unscheduled Downtime, Scheduled Downtime, Engineering, Standby, Productive). E10 states are derived from the processing state, not equal to it. Cram them into one field and the argument arrives later, in the form of a utilisation number nobody trusts.
The screen needs five fields
| Field | Example | Question it answers |
|---|---|---|
| Mode | Online Remote | Who can command this right now |
| State | Starting | What the equipment is doing |
| Command | Start requested, from sequence | What is being asked, and by whom |
| Blocked by | Discharge valve not open | Why it hasn't happened yet |
| Fault | Drive fault | What must be cleared before touching it |
The one that actually cuts radio calls is Blocked by. A "failed to start" alarm arrives too late and names no cause. "Discharge valve not open" lets the operator decide the next action standing where they are. You do not need the full permissive list on an overview screen — show only the failed condition, top of the list, one line. Push the complete list into a popup and unfold it during commissioning.
Do not draw a comms loss as Stopped
The most common bug lives in the default case of a display script. The PLC state value arrives as an undefined number, or comms drop and a stale zero stays behind, and the display falls through to "Stopped." Stopped is a normal state, so its colour is quiet and no alarm fires. Nobody notices.
This is not fixable on the screen; it is fixable in the tag. The evaluation priority belongs in the derived tag — as laid out in derived status tags, BadQuality has to sit above Running.
One preference of mine: unknown values do not get grey. Grey is already spoken for by maintenance mode. Hatching plus the words "no value" makes an operator ask about it at least once, and that is the correct outcome — better than something that quietly looks normal.
What to actually test at commissioning
Per equipment class, not one pump on one screen.
- Force the PLC state value across its full range. Confirm undefined values render as "no value" and not as "Stopped."
- Pull the comms cable. Watch how many seconds the screen takes to change, and whether the result is visually distinct from stopped.
- Drive each permissive false one at a time and check the Blocked by text. Plenty of implementations report the wrong condition once the list order changes.
- Put the tool in LOCAL and send a remote command from the host. See whether the screen says "refused, equipment in LOCAL" or whether nothing visible happens at all. If it is the latter, you are short a field.
- Test failed-to-start and failed-to-stop timers against real delays. Three seconds chosen at a desk is usually short.
- Confirm mode changes are logged as events, with who and when attached.
That last one gets used more than any of the others later. "Who turned remote off" is an argument that never ends without a log.
One problem that stays
The HMI's mode field and the control state the host is holding are the same fact drawn twice. They will disagree at some point — the classic window is equipment that has dropped to LOCAL while the host still believes it is REMOTE. Log both, each with a timestamp and a source. What you want afterwards is not which one was wrong, but when they diverged.
If you want to push these transitions around against real host code, you can connect over HSMS to the SECS/GEM simulator and try them.