HMI indicator buttons not changing: trace the tag value path

What the pattern points to

Match your symptom to a cause before you touch anything:

• One to three objects stuck, the rest of the screen updating. The link and the driver reach the panel, because the neighbors prove it. The fault is in what each stuck object reads, or in how it maps the value to a displayed state.
• The same fault on more than one screen. Settings copied at object creation, or a tag shared by several objects. Audit the tags and the object defaults across screens, not just the screen you are standing at.
• The tag changes at the controller but lands on the opposite state from the rung you watch. Two rungs can drive the same coil, and the last one scanned wins; why double-coil PLC logic ignores the first input explains the mechanism. Check the program before you blame the panel.
• Values arrive but read as nonsense. A data type mismatch at the object. Nonsense numbers from a PLC BCD analog register shows what that looks like and how to sort it.
• Every value on the panel goes stale at once, or flickers panel-wide. The comms path or the panel supply. This is the only pattern in the list that points at power or wiring.

The first two patterns cover the fault this article works through: a minority of indicators stuck, on one screen and then on others.

Check the value the panel receives first

Watch the tag at both ends before you edit anything. At the controller, force or toggle the tag and confirm it changes in the controller's own monitor. At the panel, open the programming software's on-line or tag monitor, or the panel's diagnostics, and read the value the panel itself holds for that tag. The decision follows from what you see:

• The value never changes at the panel. Work the path: driver selection, the address the object reads, cable and connectors, comms settings. The article on checking the PLC serial protocol before replacing a legacy HMI lists what to match before you order anything.
• The value changes at the panel but the graphic stays put. The path is good. The fault is in the object's tag, data type or state mapping, and the next section is your job.

One more pattern sits between those two: a tag that sits at one value for every object that uses it. Some panels refresh a tag only in certain acquisition or update modes, so the tag can hold its first value all shift. The three checks to run are the tag's reachability in the connection, the field's process-value binding, and the display refresh or update mode set for that tag in the project. Your panel's own manual names where each lives.

Compare one stuck object with a working neighbor

Take one stuck object and one working indicator on the same screen, and walk the settings side by side:

1. Record three version numbers as three values: the panel model, the project software version, and the panel firmware version. One number shown on the panel is not both software and firmware, so read each from where it lives.
2. Compare the tag or address each object reads. Confirm the stuck object points at the tag the program actually writes, not an address one digit away.
3. Compare the data type on both objects. A bit read as an integer, or an integer read as a bit, maps to different states.
4. Compare the state mapping: how the object turns a value into a displayed state, and the bit width it expects. Message limits and bit width for multi-state indicators covers what the object needs to see.
5. Compare visibility and animation conditions. A condition that has gone false can hold an object hidden or frozen while its state tag carries on; object visibility with two conditions on one PLC tag shows how to keep one tag in charge of the display.
6. Watch both objects live while the machine is in a safe state and the tag changes. Note which one moves.
7. Repeat on the second screen where the fault appears. The same setting wrong on both screens points at a project default or a copied object. Different settings wrong on each screen point at individual objects.

If the comparison finds a wrong data type on many objects, correct the tag's data type once and re-link the objects; changing a tag data type without rebuilding every object walks that job.

Example: 3 of 19 indicators stuck on one screen

Inputs. A 15-inch panel on a plant floor runs one screen with 19 indicator buttons. Three of the 19 hold one state while their tags change. The tag monitor at the panel shows all three values changing, so the panel receives them. The same symptom shows up on at least one other screen, again on a minority of objects. The panel is powered from 120 V AC through a step-down DC adapter.

Rule. A fault on the comms path or in the supply starves every object on the panel together. It cannot hold exactly three graphics frozen while sixteen update normally through the same cable and driver. A partial failure therefore isolates the cause to the objects themselves: what each one reads, and how it maps the value to a state.

Arithmetic. 19 − 3 = 16 indicators updating normally on the same screen, through the same link. The affected share is 3 ÷ 19 = 0.158, about 16% of the screen's indicator objects.

Result. The link, the driver and the supply are ruled out for this screen by the 16 live neighbors. The fault sits in the configuration of the 3 stuck objects: tag, data type or state mapping. The repeat on a second screen means the audit has to cover every screen that uses these indicators, because the wrong setting can sit anywhere a copy carried it.

Decision. If even one indicator on a screen updates while another sticks, close the power and comms questions and audit objects, screen by screen, before the panel ships. If the stuck count reaches the whole screen, 19 of 19 on this one, power, comms and firmware come back into play. Here, 16 updating against 3 stuck puts the work on the three objects.

What not to change while you diagnose

• Rebuild an object once, not five times. One delete-and-redraw is a fair test of a damaged graphic. In this example the redrawn buttons stuck the same way, which is a result: the fault travels with the configuration the object carries, so more rebuilds only erase evidence.
• Leave the controller program alone until the tag monitor has told you which side the fault is on. The tags were verified changing at the controller, so logic edits add a new variable to a fault that is already isolated.
• Do not replace the panel. Sixteen of nineteen indicators on the same link talk correctly. Hardware that misses three graphics out of nineteen while updating the rest does not match the profile of a dead panel.
• Do not update firmware on a guess. Old panel firmware releases have carried known defects that left individual indicators stuck, and the affected builds are a question for the panel maker's support, asked with your model and versions in hand. Read the installed versions first, as in step 1 of the comparison above.
• Check the calendar against the fault. If the stuck or missing values began right after a controller firmware update, confirm both versions before editing objects. Updates have taken values off screens with nothing changed on the panel side, so a version step is the first thing to line up with the date the fault appeared.

Power, comms and versions come last

Bring the electrical checks in when the panel-wide pattern shows up: every value stale at once, flicker across the whole screen, or a panel that reboots when large loads start.

• Inspect the supply wiring for loose terminals and for runs shared with switched loads.
• If the panel's manual allows it, power the panel from a separate, correctly rated 24 V DC supply and retest the same screens. The example panel ran from 120 V AC through a step-down adapter, and a clean 24 V DC source is the standard test for noise on the supply.
• Watch a working indicator and a stuck indicator during the retest. If both behave the same on the clean supply, the supply is out of the picture for this fault.

If the tag monitor still shows stale values panel-wide after these checks, stop editing and take the evidence to the panel maker's support: model, both version numbers, a copy of the project, and the stuck-versus-working comparison.

Restore production and verify the fix

When the line has to run now: move the indication. A pushbutton with its own indicator lamp separates the input from the display, and it gives operators a working light while the object audit continues. Test the press action and the lamp separately, and write down which objects were swapped so the workaround is never mistaken for the repair.

When the cause is confirmed: correct exactly what the comparison found. Fix the tag or address on the stuck objects, fix the data type or state mapping, or fix the comms or supply fault the panel-wide test identified. Apply a version change only with the panel maker's confirmation for your model and build.

Verify on every screen, not just the bench screen:

1. From the controller, force each affected tag on, watch the object change, force it off, and watch again.
2. Keep the tag monitor open so you see the panel receive each change.
3. Repeat on every screen that uses the affected tags.
4. Power the panel down and up per the vendor's documented procedure, then repeat the both-states test after startup.

Safety note: force or toggle tags only with the machine in a safe state, its normal interlocks live, and the operators told that the indication is under test.

Recommendation: when a minority of indicators stick while their neighbors on the same screen update, stop replacing objects and stop editing the controller program. Watch the value at the panel with the tag monitor, then audit each stuck object's tag, data type and state mapping against a working neighbor on that screen, and repeat the audit on every screen that uses those tags before the panel ships. Bring power, comms and firmware into it only when every object on a screen goes stale together.

Questions