Learn Automation with MINATA #41: Basic HMI for Machines — The Screen Must Help the Operator, Not Just Look Good

Basic HMI for machines: the screen must help the operator, not just look good

The HMI is where the operator sees the control system. A good screen lets them tell at a glance which mode the machine is in, what condition it is waiting for, and what to do when a fault appears. A poor screen forces the operator to guess, press buttons at random, and call maintenance for things that should have been self-explanatory.

What an HMI needs to show

Four groups of information are almost always present:

Machine state: Idle, Running, Hold, Fault or Home. The operator must read the state in a single glance.
Mode: Manual/Auto, and who currently holds control (local or remote).
Operating commands: Start, Stop, Reset, Jog — each with its enabling condition, not "press and it runs".
Warnings and faults: the list of active alarms, when they appeared, and how to handle them.

Layer the screens

Do not cram everything onto one page. A common structure has an overview page for the whole machine, detail pages for each mechanism group, an alarm page with history, and a settings page limited by permission. The operator moves from overview to detail when needed, instead of scrolling through dozens of buttons to find one value.

Colour and alarms are a language, not decoration

Reserve strong colours (red, amber) for abnormal conditions, and keep the background and normal states in neutral tones. If the whole screen is vivid, the operator's eye loses the ability to spot what is actually wrong. Every alarm should carry a priority level, a clear description, and a suggested action; avoid "nuisance alarms" for conditions that need no intervention, because they teach the operator to ignore everything.

Command, feedback and confirmation

Keep three things distinct on the screen: the command sent, the real feedback from the device, and the result. A lit Run button does not mean the motor is turning; take the Running state from the drive feedback or a sensor. For risky actions (jog with a door open, overriding a limit), add a confirmation step to avoid an accidental touch.

A MINATA engineering reference

On MINATA machine cells, the HMI shows three separate fields for a motor: the Run command, the Running feedback and the drive Fault. The operator never confuses "I pressed start" with "the motor is running"; when a fault occurs, the alarm page points to the exact unit and drive error code to shorten the search.

Layout, colours, thresholds and access rights must ultimately follow the machine's documentation, the applicable standards and the customer's requirements.

Common mistakes

Designing the screen for aesthetics before agreeing what the operator needs to see.
Showing state from a command bit instead of real device feedback.
Cramming every button and value onto one page with no layering.
Alarms without priority levels or handling guidance.
Allowing parameter edits on the HMI with no permission control and no audit trail.

HMI design checklist

[ ] Machine state and mode are readable at a glance.
[ ] Commands carry an enabling condition and real feedback.
[ ] Strong colours are reserved for abnormal states; alarms have levels and guidance.
[ ] Screens are layered: overview → detail → alarm → settings.
[ ] Parameter edits are permission-controlled and logged.

A good HMI turns a complex control system into something the next shift still uses correctly. Article #42 looks at how to connect the HMI to the PLC: designing tags and states before pulling any wire.

Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation

Previous — #40: Encoders and position feedback: https://minatavn.com/en/blog/automation-40-encoders-position-feedback

Next — #42: Connecting HMI and PLC: design tags and states before pulling wire: https://minatavn.com/en/blog/automation-42-hmi-plc-connection

View all MINATA technical articles