A PLC can drive an HMI's alarm and warning backlight colors through the project's PLC-to-panel setup word: red when the alarm bit is on, amber when only the warning bit is on. Map one word, write it on change, give screen navigation a single owner, and test every state and transition at the panel before the line runs again.
Yes, and the clean version takes one mapped word and one owner per job. The project software's PLC to Panel setup words are PLC memory locations that select panel functions, backlight color included. Two bits in the PLC, one for an alarm and one for a warning, are enough to hold the panel red on an alarm and amber on a warning. Screen changes are a separate function with their own failure modes, so this article keeps the two jobs apart: the color word first, navigation second. For the screen side in depth, the article on changing HMI screens from the PLC covers it.
What the setup word controls
Open the project's setup and find the PLC to Panel menu; the PLC->Panel tab holds the setup words. Each setup word is a PLC memory location tied to a panel function, and the backlight color function takes one of them. You assign the location in the project, the PLC writes that location when the machine's state changes, and the panel follows the word. How fast a written value lands on the glass is one of the things your commissioning test measures, because it is a link round trip, not an output coil.
Two documented facts set the rest of the design. First, the panel's user manual states that loading a project overrides whatever color was chosen on the System Setup screens' Backlight color selection, so a color picked at the panel dies at the next download. The color lives in the project mapping and in the word, nowhere else. Second, the value for each color comes from the project's own setup-word configuration; a value copied from another project is a guess. The PLC owns detection and the project owns presentation, and keeping that split in your code comments is worth the two minutes it takes.
What you need
- The HMI project file, with its revision noted
- The PLC program, with the alarm and warning conditions already coded as two discrete bits
- One free word in the PLC that both the project mapping and your logic can reach
- The color value list from the project's setup-word configuration
- A way to force the two bits online, and a person standing at the panel while you test
Example: two bits, one word, red wins on a packaging line
Inputs. One backlight color word, assigned in the project's setup words; this example calls it W_COLOR, and the real address is the one your project assigns. Two PLC bits coded from the line's diagnostics; this example names them B_ALARM and B_WARNING. Three color values taken from the project's mapping table; this example calls them V_NORMAL, V_AMBER and V_RED, each the value your project lists for that color.
Rule in words. One writer. The PLC encodes the two bits into the word with the alarm on top: alarm on writes V_RED, alarm off and warning on writes V_AMBER, both off writes V_NORMAL. The word moves only when the encoded value changes.
Arithmetic. Two independent bits give 2 x 2 = 4 combinations. The mapping folds them to 3 visible panel states: both off to normal, warning only to amber, alarm only to red, both on to red. The alarm wins in 2 of the 4 combinations. The write-on-change rule earns its keep at scan speed: at a 10 ms scan time, a word written every scan reaches the panel 1000 ms / 10 ms = 100 times per second, while a full event written on change takes 3 writes, red at the alarm rise, amber at the alarm-to-warning handoff, normal at the clear.
Result. The panel shows red whenever B_ALARM is 1, including when B_WARNING is 1 with it, and amber only while the warning stands alone.
Decision. Default to alarm-over-warning: a fresh alarm outranks a lingering warning unless your process says otherwise. If warning must win, the swap changes exactly one combination, both bits on, so swap the two checks in the encode logic and retest that single case.
Give screen changes one owner
The color word and the screen number are separate jobs, and split ownership is where the mess starts. Two behaviors matter at design time. A recipe action that writes a "switch to screen" value is a fragile way to return to the previous screen. And screen-change commands written from the PLC have landed very slowly or not at all in some installations. Adding delays, or repeating the command faster, hides the symptom and leaves two navigation paths armed at once.
The pattern that holds: the operator navigates with the panel's own change screen buttons, and the PLC reacts to the screen indication value instead of the keypress. Edge-trigger the logic on the indication so a follow-up calculation fires once per arrival and stays quiet while the screen stays put. If a transition genuinely must come from the PLC, strip the bench test to one navigation source, watch the indication while the command runs, and time how long the panel takes to act. A screen change and a color change are separate results, and each one gets its own look at the panel.
Steps to commission it
- Record the panel model, the project revision, and the PLC address assigned to the color word, in the project notes where the next engineer will find them.
- In Setup > PLC to Panel, on the PLC->Panel tab, assign the backlight color function to one word. Copy each color's value from the project's own mapping table.
- Leave one writer on that word. No recipe object, no second screen, no leftover test logic writes to it.
- Code the encode with the alarm on top, and move the word only when the encoded value changes.
- Test the color alone: force the alarm bit, watch the word change online, then look at the panel. Clear it, force the warning bit, look again, clear it.
- Add navigation last: the operator's change screen button owns screen moves, and the PLC edge-triggers its follow-up logic on the screen indication.
- Run the combined checks in the next section, then return the panel to service.
How to check it worked
- The word. The value changes online the moment you force the bit, and it changes back on clear.
- The glass. Red on alarm, amber on warning, normal color on clear, each one seen with your own eyes at the panel.
- The both-bits case. With alarm and warning on together, the panel shows the color you chose for that case, red by default.
- The transitions. Alarm to warning, warning to normal, alarm to normal. Run the full alarm-warning-clear cycle five times before sign-off, and count five clean passes before you walk away.
- The brightness. At least one HMI reference manual warns that approaching 0% backlight, changes in brightness may no longer be noticeable. A panel idling near the bottom of its brightness range swallows the color you just wrote, so keep the alarm-time brightness well clear of 0%.
- The dim state. If the project uses a backlight saver timeout or wakes the backlight from a PLC event, force an alarm from the dimmed panel and confirm it wakes into the alarm color; if it stays dim, the wake logic or the saver timeout is the thing to change.
- The indication. The PLC follow-up fires once per arrival at a screen, and again only after the screen moves away and back.
Recommendation
Recommendation: give the PLC the color word and the operator the screens. Map the backlight color function to a single setup word on the PLC->Panel tab, encode two bits with the alarm on top, write on change, navigate with the panel's change screen buttons, and edge-trigger PLC follow-up logic on the screen indication. Sign the panel back into service only after the sign-off passes in the checklist above, with the both-bits-on case first. If screen changes stay slow after you have isolated the writer and confirmed the mapping, stop adding delays: capture the project revision, the word mapping, and one repeatable failing transition, and take them to the panel vendor's support. The wider shop-floor screens checklist, from mounting to brightness planning, lives in the factory section.
Questions
Why did the backlight color I picked on the panel's setup screen disappear?
A project download overrides whatever color was chosen on the System Setup screens' Backlight color selection, so a color picked at the panel is gone at the next download. The mapping you configured in the project loads as part of the download, so the PLC word keeps working; only the panel's own pick is lost. Re-picking a color at the panel buys a color that lasts until the next download, which is why the color belongs in the project and the word.
Do all HMI platforms support PLC-driven alarm colors?
The feature is documented across several major HMI platforms: an alarm state in the PLC drives the screen background or the backlight color. The route shown here, a setup word on the PLC->Panel tab, is one documented implementation; other platforms reach the same result through their own alarm color settings. The menu names and the color values always come from the platform's own project software, never from another project.
Should the alarm also force the panel to the alarm page?
Only if the process needs it. The color word and the screen number are separate panel functions, so the frame can stay red while the operator reads whichever page they need; the alarm color does its job without a forced navigation. Reserve PLC-driven screen moves for cases where the operator must see one specific page, and weigh the reported slowness of PLC-written screen changes before you add one.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.