Operator-screen builder field guide
HMI simulator: tag binding, button modes, alarm states and screen testing
Direct answer
An HMI simulator lets you build an operator screen and test it against running control logic before any panel exists. The useful test is not whether the graphic looks right, but whether each button writes the intended tag, each lamp reflects real PLC state, alarms move through acknowledge and clear correctly, and navigation reaches every screen the operator needs.
This guide is written for controls learners, maintenance technicians moving into HMI work and instructors who want operator-screen exercises that fail visibly when a binding, button mode or alarm rule is wrong. The intended result is specific: the learner can bind widgets to the correct tags, choose momentary or latched behavior to suit the PLC logic, set display ranges, define alarms with severity and deadband, and prove the finished screen against a scripted operating sequence.
Tag contract
Before placing a widget, write down which tag it reads or writes, its data type and who else writes it. A lamp bound to a status bit, a numeric entry writing an INT setpoint and a selector writing a position index each carry a different contract, and most screen faults are a broken contract rather than a broken graphic.
Momentary versus latched
A momentary button holds its tag true only while pressed; a latched button toggles and keeps the value. Start and stop commands are normally momentary because a seal-in rung owns the run memory. The builder stretches a very quick click to a short minimum pulse so the scan cannot miss it, which mirrors why real panels care about pulse width.
Command versus feedback
Pressing Start is a request. The running lamp should be bound to evidence that the PLC decided to run, or better to an auxiliary feedback input, not to the button tag itself. Binding a lamp to its own command makes the screen report success even when an interlock blocks the output.
Display range and units
Gauges, level bars, sliders and trends take a minimum, maximum and units label. That range only positions the value on the widget; it does not convert raw counts into engineering units. If the PLC tag holds raw data, scale it in logic first, then set the widget range to the real process span.
Alarm lifecycle
Each alarm is a condition on a tag, on, off, above or below a limit, with a severity from low to critical and an optional deadband. It moves between normal, active unacknowledged, active acknowledged, cleared unacknowledged and shelved. Acknowledging confirms the operator has seen it; only a cleared and acknowledged alarm leaves the summary.
Screen structure
A project can hold several screens. The first is the home screen, navigation buttons either replace the current screen or open a pop-up faceplate, and a button whose target screen has been deleted does nothing. An overview that routes to detail screens and an alarm summary scales better than one crowded panel.
- 01
List the operator tasks
Write what the operator must start, stop, adjust, confirm and respond to, and name the PLC tag behind each action and indication.
Evidence: Every widget planned for the canvas traces back to a task and a named tag with a stated direction.
Avoid: Dragging widgets onto the canvas first and hunting for tags afterwards.
- 02
Place and bind in Configure mode
Add each widget, bind it to its tag, set pushbutton mode, ranges, units and selector positions.
Evidence: No widget remains unbound, and each binding matches the direction and type on the tag list.
Avoid: Binding a status lamp to the command tag because the names look similar.
- 03
Run the normal sequence
Switch to Run mode and operate the screen exactly as the exercise brief describes, one action at a time.
Evidence: Lamps, numbers and trends change only after the scan updates the tags they read.
Avoid: Judging success by the button highlight rather than the feedback indication.
- 04
Exercise the interlocks
Hold a permissive false, such as an overload or guard input, and press the command again.
Evidence: The command tag changes but the output and running indication stay off, proving the PLC owns the decision.
Avoid: Disabling the button on screen and calling that the interlock.
- 05
Drive the alarms
Push each alarm tag across its limit, acknowledge it, clear the condition and repeat in the opposite order.
Evidence: The summary shows the expected state at every step and the alarm disappears only when both cleared and acknowledged.
Avoid: Testing only the raise path and never the clear-before-acknowledge path.
- 06
Check the whole project
Visit every screen from home, open each faceplate, then run the built-in screen check.
Evidence: Navigation reaches every screen and the grader reports each requirement row as passed.
Avoid: Leaving an orphaned screen or an inert navigation button in the finished project.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| Lamp never lights in Run mode | Widget binding, tag spelling, the scenario tag list and whether any logic writes that tag | An unbound lamp, a lamp bound to an input nobody drives or a rung that never goes true all look identical on screen. | Bind a spare lamp to the upstream command tag; if the command changes but the status never does, the fault is in logic or a permissive, not the widget. |
| Motor stops when Start is released | Pushbutton mode, seal-in branch and the tag the holding contact uses | A momentary button needs a seal-in rung; without one the output follows the button and drops as soon as the pulse ends. | Add or repair the seal-in in logic rather than switching the button to latched. |
| Latched button snaps back after one scan | Other writers of the same tag, especially an output coil or reset rung in the PLC program | Two owners are writing one tag and the PLC scan wins, so the HMI write is overwritten on the next pass. | Give the HMI its own request tag and let logic decide the resulting state. |
| Alarm stays in the summary after the fault clears | Alarm state, acknowledgement history and whether the condition has truly returned to normal | Cleared but unacknowledged is a deliberate state: the operator has not confirmed seeing the event, so it stays listed. | Acknowledge it; if it still remains, check the limit and deadband against the live value. |
| Gauge pinned at full scale or near zero | Widget minimum and maximum, the tag units and the range of values the PLC actually writes | A raw count shown on a 0 to 100 widget, or a percentage on a 0 to 1,000 widget, gives a misleading picture without any error. | Scale the value in logic and set the widget range to the real process span. |
| Display frozen while the process should be moving | Run mode status, the bound tag, and whether the value is written only by logic that is currently idle | The simulator does not model communication loss or tag quality, so a frozen value here means a binding or logic issue, not a dropped link. | Confirm Run mode, then trace the writer of the tag; on a real HMI, also check quality and driver diagnostics. |
Product evidence / 05
What the browser practice can actually demonstrate
The HMI Builder places pushbuttons, lamps, numeric displays and entries, gauges, level bars, sliders, selectors, trends, alarm banners, alarm summaries and navigation buttons on a canvas, then runs them against the simulated PLC scan. Exercise grading first checks that required widgets exist with the right tag and button mode, then runs the exercise program on a fresh engine and executes a check sequence.
What is the best way to practice HMI design without a panel?
Build a screen against running logic and try to break it. Bind commands and feedback to separate tags, block an interlock, push alarms across limits and navigate every screen. A drawing tool or screenshot course cannot show you a button that writes the right tag while the PLC refuses to act.
Should an HMI start button be momentary or latched?
Momentary in most motor circuits. The PLC holds the running state through a seal-in or latch, and a stop press breaks it. A latched start button would leave the command true after a stop or trip, which can cause an unexpected restart. Use latched buttons for deliberate operator toggles the logic reads directly.
What is the difference between acknowledging and resetting an alarm?
Acknowledging records that an operator has seen the alarm; it does not remove the cause. Resetting is a separate machine action, usually a PLC command, that clears a latched fault after the cause is gone. In this builder, an alarm leaves the summary only once its condition has cleared and it has been acknowledged.
Why does my HMI value look wrong even though the tag is correct?
The widget range or units usually disagree with what the tag holds. A gauge set to 0 to 100 will sit at full scale if the PLC writes raw input counts. Check the scaling in logic, then set the widget minimum, maximum and units to the real engineering range.
Can an HMI button be used as a safety interlock?
No. Hiding or disabling a button is a convenience only, because other screens, clients or a fault can still write the tag. Permissives must be enforced in PLC logic, and emergency stop and other safety functions belong in the hardwired or safety-rated system defined by the risk assessment.
Does this simulator model tag quality or communication loss?
No. Widgets read and write tags inside the browser training engine, so there is no driver, network or quality flag to fail. On a production HMI you should also design stale-value indication and test what the screen shows when communication drops, using the target product documentation.
Can I set up operator log-in levels in the HMI Builder?
No user roles or passwords are modeled. Treat access control as a requirement to specify and test in the target HMI product. In practice sessions, focus on the PLC side: validate every written setpoint in logic so a wrong value is rejected whoever enters it.
Will these screens import into FactoryTalk View or WinCC?
No. Projects stay in the browser builder. The transferable part is the method: a tag list, command and feedback separation, button modes, alarm rules and navigation structure. Rebuild the screen in the vendor software and repeat the same tests there before any commissioning.