Most HMI numeric display objects have static colors. Bind two identical copies to the same process tag, stack them at the same coordinates, and let the alarm bit drive opposite visibility conditions, so the alarm copy appears in red. Match the value binding, decimal places, units and character height in both copies.
Most numeric display objects on an HMI screen animate the value they show and nothing else: the colors are fixed at design time, and there is no property to bind to the discrete alarm tag. The fix that works on any runtime with object visibility is an overlay. Put two identical numeric displays at the same coordinates, bind both to the same process tag, and drive opposite visibility conditions from the alarm bit. One copy carries the normal appearance, one carries the alarm appearance, and the bit decides which one the operator sees. The value never changes, only its colors. This article gives the bindings, the settings that must match, the checks that catch a broken swap, and when a native color animation is the better build.
Two displays, one alarm bit
The process value and the alarm state are two signals, so the screen needs two behaviors: digits that track the analog tag, and an appearance that tracks the bit. The overlay gets the second behavior from the same visibility mechanism you use to gate an HMI button on a PLC timer done bit: one condition, one object. The alarm bit turns one copy off and the other on, at the same spot on the screen, so the swap reads to the operator as one object changing color.
If the thing you want to color is an indicator lamp and not the value itself, that is a lighter build, and showing three alarm states with one HMI indicator covers it. This article is about the value readout, where the digits have to keep coming from the process tag.
What you need
- The numeric process tag the value comes from, with the format you want to show: decimal places and unit text.
- The discrete alarm tag, one bit the controller sets on the alarm condition and clears on reset. The screen reads it; the controller owns it.
- An HMI package whose screen objects support a visibility animation. In one widely used package the documented path is Properties → Animation → Add New Animation → Visibility, with the condition set to a process tag.
- A screen editor that places two objects at the same coordinates and controls which one is in front, through its layer or z-order setting.
- A force or test mode in the controller, or tag simulation in the editor, so you can drive the bit both ways without touching the process.
Check the object's animation list before you build anything. If your package offers a color or appearance animation that accepts a discrete tag, bind the bit to that and you are finished. The overlay is for the packages where color is fixed at design time, which is the common case.
Build the overlay step by step
- Write both tags down before you touch the screen: the process tag for the value, and the alarm bit.
- Place the first numeric display object, bind it to the process tag, and set the format: decimal places, unit text, font and character height.
- Copy the object and paste it at the same coordinates, so the two sit exactly on top of each other at the same size.
- Change only the colors. The tag binding, decimal places, unit text, font and size stay identical. For example, normal copy white digits on a black background, alarm copy black digits on a red background.
- Set the visibility from the alarm bit: the normal copy visible when the bit is 0, the alarm copy visible when the bit is 1. Use the same bit in both conditions so exactly one copy is on screen in every state.
- Bring the alarm copy to the front in the layer order, then check that order at the panel's real resolution, not only in the editor.
- Save, download to the panel, and keep the previous screen file so you can roll back.
Keep both copies readable
Size the digits for the farthest operator. The planning figure for fast reading is 20 ft of viewing distance per inch of capital letter height; the FHWA figure of 30 ft per inch suits deliberate reading of a familiar layout. An alarm readout is read at a glance, so use the 20 ft figure. Both copies must share the same character height, because the alarm state changes colors, not size.
Give each state at least a 3 to 1 contrast ratio between digits and background, the large-text minimum in the Web Content Accessibility Guidelines. The normal pair is easy: white on black reaches the 21 to 1 ceiling of that scale. The alarm pair is where overlays fail the number, usually dark red digits on black or red on a red-tinted background, combinations that still look acceptable on the bench.
Example: a furnace readout at 10 ft
An operator reads a furnace temperature from 10 ft away. Call the process tag Temp_PV and the alarm bit Temp_Hi_Alm; the controller sets the bit above 240.0 °C. The display shows one decimal place with the unit °C.
Character height: 10 ft ÷ 20 ft per inch = 0.5 in of capitals. The FHWA figure would allow 10 ft ÷ 30 ft per inch = 0.33 in, and you take 0.5 in because an alarm value is read fast. Both copies get exactly that height.
| Setting | Normal copy | Alarm copy |
|---|---|---|
| Value tag | Temp_PV |
Temp_PV |
| Decimals, unit | 1, °C | 1, °C |
| Capital height | 0.5 in | 0.5 in |
| Digits | white | black |
| Background | black | red |
| Visible when | Temp_Hi_Alm = 0 |
Temp_Hi_Alm = 1 |
At 238.4 °C the operator sees white digits on black. When the controller sets the bit at 240.0 °C, the white copy hides, the red copy shows the same tag reading 243.6, and the digits are black on red. Same value, same decimals, different appearance.
Check the swap at the panel
- Bit at 0: exactly one object visible, normal colors, value matching the controller.
- Bit forced to 1 in the controller's force or test mode: the alarm copy shows, with the same digits, decimals and unit. Never trip the real process limit to see the color change, and clear force mode before you leave the panel.
- Bit back to 0: the normal copy returns. Cycle the bit several times and watch for a blank frame, both copies at once, or a stale value.
- If the value is scaled, confirm both copies share the scaling; mismatched decimal scaling between two objects is the trap described in showing decimal flow values on an HMI numeric display.
- Break the tag link per your site procedure and see which copy stays. Runtimes that evaluate the visibility condition as false on bad quality leave the normal copy on screen while the tag is dead, and a dead tag then looks like a healthy process. Add a communication indicator if yours behaves that way; the pattern is the one behind fixing an HMI communication timeout when outputs hold state.
- Record the two objects as a pair in the screen documentation, with both tag names, so the next editor keeps the bindings matched.
When one object is the better build
If your package's numeric display has a color or appearance animation that accepts a discrete tag, bind the bit to it and delete the overlay: one object, nothing to keep matched. Prove it with one full alarm cycle at the panel before you rely on it. If the specification asks for blinking, check the runtime for a blink property or flash the appearance from a toggling bit; a steady value beside a blinking indicator keeps the digits readable. And if the alarm has to be read from the line rather than at the panel, a small readout is the wrong tool: a separate status screen carries it, and our shop-floor signage is built for that spot.
Recommendation: Use the two-display visibility overlay whenever the numeric display object has no color animation that accepts the alarm bit, which is the common case. Keep both copies bound to the same process tag with identical formatting and the same character height, drive the two visibility conditions from the one alarm bit, and record the pair in the screen documentation.
Questions
Can the alarm copy blink as well as change color?
Only if the runtime offers blink. Some packages flash an object from the alarm system's own flash bit, and some let a visibility condition follow a bit the controller toggles. If neither exists in your package, put a separate blinking indicator beside the value and keep the digits steady, so the number stays readable while the blink pulls the eye.
How do I test the swap without causing a real alarm?
Force the discrete alarm bit from the controller in its force or test mode, or simulate the tag in the editor if the software supports simulation. Confirm the alarm copy appears with the same digits, then release the bit and confirm the normal copy returns. Clear force mode before you leave the panel, and log the test with the screen revision.
What happens to the overlay if the alarm tag loses communication?
Test it and see, because packages differ. Many evaluate the visibility condition as false when tag quality goes bad, which leaves the normal copy on screen while the tag is dead and the panel looks healthy. Cover that case with a communication fault indicator on the same screen, driven by the link status, so a dead alarm tag never reads as a normal process.
Can the overlay show more than two states?
Yes. Stack one copy per state and give each its own mutually exclusive visibility condition on a state tag, for example two bits encoding normal, warning and alarm. Every copy stays bound to the same process tag with identical formatting, so only the appearance changes across states. For a plain indicator with no digits, one multi-state indicator object is the lighter build.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.