The operator needs an explanation, not your memory map
The machine is stopped. Its screen shows twelve green lamps, one grey button and the word “AUTO.” The programmer knows that bit 17 of a permissive word is false. The operator knows only that production has stopped.
A useful HMI answers four questions quickly: what is happening, what should happen, what prevents it, and what action is available? Design those answers alongside the sequence. If the program cannot explain why it is waiting, a beautiful screen cannot recover the missing information.
Use the operator's task as the starting point. Starting a batch, changing a format, finding a blocked sensor and recovering a transfer are different tasks. They should not all require visiting a generic page containing every writable tag.
Show the difference between desired and actual
For a filling station, the overview might say: “Filling container 24 — target 500 g — measured 318 g.” If the station pauses, replace vague status with “Waiting for outlet clamp closed.” The displayed condition should come from the same defined evidence the sequence uses.
Display command and feedback separately when the distinction matters. “Valve requested open” and “Open feedback missing” explain a fault. A valve graphic coloured solely from its command can hide it. The chapter on Motors and drives uses the same distinction.
Keep stale measurements visibly stale. A disconnected HMI that freezes a normal-looking screen can mislead someone into trusting an old state. Show connection health, value quality and data age where the operating decision requires them. Do not let a greyed-out graphic silently carry three unrelated meanings.
Buttons submit requests
The HMI should ask the PLC to perform an action. The PLC remains responsible for accepting or refusing it against the current state and permissions. A disabled button helps the operator, but it is not the control boundary: another client, an old screen or a network race can still submit a request.
For a start request, show acceptance or a specific reason for refusal. If a batch cannot start because its recipe has not passed validation, say that. A short-lived click followed by no visible response encourages repeated clicking and makes later duplicate handling harder.
For consequential operations, a request identifier is often clearer than a shared Boolean that both HMI and PLC try to reset. The HMI publishes a new request; the PLC returns the corresponding result. The implementation depends on the HMI platform, but the ownership rule is stable: one component owns the request, another owns the response.
Treat numeric entry as a proposal
An operator types 650 into a temperature field intended for 65.0 degrees. The screen can catch the mistake, but the controller must validate it too. Supply units, permitted range and the currently accepted value next to the entry.
For related parameters, use an edit-and-apply workflow. Let the operator review the whole proposal before the PLC validates and accepts it. During an active batch, show both the active recipe and the pending edit if changes are allowed for the next batch. Otherwise somebody may believe the displayed new target already controls the current product.
This body excerpt illustrates the receiving side of a proposed setting. It assumes request IDs are initialised and managed to avoid unintended acceptance after restart. It is not a complete HMI communication protocol.
IF ProposedRequestId <> LastHandledRequestId THEN
LastHandledRequestId := ProposedRequestId;
SettingAccepted := FALSE;
IF MachineIdle
AND (ProposedSpeed_mm_s >= 50.0)
AND (ProposedSpeed_mm_s <= 400.0) THEN
AcceptedSpeed_mm_s := ProposedSpeed_mm_s;
SettingAccepted := TRUE;
SettingResult := 0;
ELSE
SettingResult := 1;
END_IF;
ResultRequestId := ProposedRequestId;
END_IF;A real implementation should distinguish “machine active” from “value outside range” instead of returning one generic error number. The example keeps the ownership and acceptance sequence easy to see. Permissions and any required user attribution belong in the complete interface too.
Build a visual hierarchy around decisions
The overview should reveal the production state and the location of a problem. Equipment detail should explain commands, feedback and permissions. Diagnostic pages can expose addresses and raw words for trained maintenance staff. Keeping those levels connected lets people move from symptom to evidence without flooding the overview.
Use colour consistently and accompany it with text, shape or position. A red-green distinction alone excludes some users and performs poorly in some lighting conditions. Reserve attention-grabbing changes for conditions that deserve attention. A screen on which every normal pump flashes teaches operators to ignore flashing.
ISA101 addresses HMI design and implementation. Use the actual standard and site conventions when specifying an industrial project; the practical screen choices here are teaching examples rather than a claim of compliance. Explore the ISA101 scope.
Recovery deserves its own design
After a transfer fault, “Reset all” is rarely enough information. Tell the operator what the machine currently believes: “Carton detected between stations; transfer result unknown.” Then provide the authorised recovery procedure appropriate to the equipment. Do not turn an HMI wizard into an invitation to enter a hazardous area; access and intervention remain subject to the machine's protective arrangements and operating procedures.
Separate acknowledge, reset and start. Acknowledging says the message was seen. Reset asks to clear an eligible latch. Start requests new operation. Combining them into a large green button makes fault recovery unpredictable.
Also design for interrupted interactions. What happens if the panel loses power while a modal dialog is open? Does an unfinished numeric entry persist? Can a second panel submit a conflicting change? A robust PLC interface should not depend on the screen being on a particular page.
Try it
A maintenance page has a “Jog conveyor” button. Press writes true, release writes false. During a jog, the network disconnects before the release arrives. The PLC retains true. Describe why an ordinary HMI button is inadequate by itself, and improve the control contract.
Work through the answer
The design assumes a release message will always arrive. Once communication fails, the PLC cannot distinguish a held button from a lost connection. The screen's appearance is irrelevant because the stale command already exists in the controller.
Use the platform's appropriate maintained-command mechanism with a defined timeout or lease, fresh communication, accepted mode and ordinary equipment permissions. Expiry removes the request and requires a new deliberate action after recovery. Test the disconnect while the button is held, not only while idle. Where the operation requires a safety-related enabling device or hold-to-run function, use the suitable engineered safety system; a network timeout in ordinary PLC code does not substitute for it.
The design lesson is broader than jogging: every human request needs a lifecycle that remains understandable when the human interface disappears.