An HMI panel reads only the tags its active screen uses, so a numeric display paints the previous visit's value until the first refresh lands. Keep each value in an internal tag refreshed by a TAG event on SYS CLOCK500MS with a 02 tag copy action every 500 ms, point the displays at the internal tags, and the stale flash is gone.
Numeric displays on an HMI panel can show the right numbers late. When the screen opens, each display paints the value left over from the previous visit for a moment before the current PLC value arrives, and the PLC registers were updated long before the screen was called. The panel, not the PLC, is holding the old number. This page explains why the panel behaves that way, how to tell a stale screen value apart from a genuine data fault, and the clean fix: a periodic event-manager copy that moves each PLC register into an internal tag on the SYS CLOCK500MS system clock, every 500 ms, with the numeric displays repointed to the internal tags. The same method covers a screen the operator sees for only a few seconds, where one flash of last cycle's numbers is enough to make the display useless.
Why does a numeric display show the previous visit's values when its screen opens?
Because the panel reads only the tags its active screen uses. A tag that no visible object needs stops being polled, so when the screen opens again the display paints the stored value from the last visit and refreshes it a moment later.
The panel polls its tags screen by screen to keep traffic off the panel-to-PLC link. When a screen closes, tags that screen alone was using drop out of the poll list, and the panel picks them up again at the next screen entry. That design is sensible on a serial link, and the cost is the one you are seeing: the first paint after entry uses whatever the panel last stored, which can be a value from the previous visit.
The PLC side is usually innocent. Confirm it once: force a new value into the register, call the screen, and watch the register and the display together. If the register shows the new value while the display still shows the old one, then corrects itself, the fault is the poll scope. If the register itself is wrong or late, work on the PLC logic instead.
What tells a stale screen value apart from a wrong value from the PLC?
Check the PLC register while the wrong value is on screen. If the register already holds the new number and the display catches up on its own within a second of screen entry, the fault is the screen's polling scope, not the PLC.
| What you see | What it points to |
|---|---|
| Old values flash when a screen opens, then correct themselves, while the PLC registers updated earlier | The panel polls only the active screen's tags; fix it with a background copy, below |
| A value stays wrong the entire time the screen shows it | Data path fault: tag address or data format; the BCD analog register walk-through is the model case |
| The screen never changes at all | Screen-change logic, a separate fault; the stuck screen-change tag fix covers that case |
How do you keep the values current while their screen is closed?
Run a periodic copy in the panel's event manager that moves each PLC register into an internal tag on every tick of the SYS CLOCK500MS system clock, then point the numeric displays at the internal tags instead of the PLC registers.
The event manager runs on the panel, outside the screen logic, so the copies keep the internal tags current no matter which screen is active. When the screen opens, the first paint reads an internal tag that was rewritten on the last clock tick, so the previous visit's numbers never reach the glass. An internal tag never holds a value older than one tick.
Internal tags are panel memory. How they behave across a power off or a project download is its own subject, and where internal tag retention survives a power off or a download covers it.
Which settings does the copy event need?
Create one event per value: event type TAG with TAG NAME set to SYS CLOCK500MS, one action in the Sequence List set to 02 tag copy, the PLC register as source tag and a matching internal tag as destination tag.
- List the displays that flash, and write down the PLC register address and expected value for each one.
- In the panel's event manager, add an event. Set EVENT TYPE to TAG, and under TAG NAME select SYS CLOCK500MS.
- In the ACTION area, add an entry to the Sequence List and check only 02 tag copy.
- Set source tag to the PLC register you recorded, and set destination tag to a new internal tag with a matching name.
- Repoint that screen's numeric display to the internal tag.
- Repeat for each value. Six displays means six events, six internal tags and six repointed objects.
- Keep one test object reading the original PLC register during commissioning, so both paths can be compared live.
The panel's event-manager help documents Tag and Tag Copy among its event actions, so this is a supported path with the names shown above. If the project already uses an event-triggered screen change driven by a PLC alarm bit, the copy events live in the same event database.
Does the hidden-object trick work instead?
It can work on a trial basis: duplicating the displays onto the screen shown before the summary screen, hidden, keeps their tags inside that screen's polling scope. Whether hidden objects keep updating is panel-specific, so test it before relying on it.
Copy the affected displays onto the preceding screen and hide them, either with a visibility setting or by sliding them off the bottom edge if the editor allows objects outside the frame. Then run the same transition test: repeated screen entries, one changed value, one unchanged value, and a watch on the link for slower updates elsewhere. The approach doubles every object you maintain, because each value now lives on two screens, and a hidden object that stops updating brings the old fault back with no visible clue. Treat it as a fallback for a single screen, and prefer the event copy when the project can take one.
Worked example: can six summary values survive a 5-second screen?
Yes. Six copy events on SYS CLOCK500MS rewrite the internal tags every 500 ms, so when the 5-second summary screen opens, every display paints a value at most 500 ms old and the previous visit's numbers never appear.
Take a machine that shows a results screen during a short rest period. The screen holds 6 numeric values: totals, averages and peaks from the exercise cycle just finished. The rest period is deliberately short, so the user gets about 5 seconds with the screen and needs the numbers right from the first glance.
The setup and the arithmetic:
- 6 copy events, one per value, each triggered by SYS CLOCK500MS. The clock ticks every 500 ms, so each event fires 2 times per second.
- 6 events x 2 fires per second = 12 register reads per second added to the panel-to-PLC link.
- Age of the displayed value at screen entry: at most 500 ms, the longest an internal tag goes without a rewrite.
- Stale share of the viewing window: 0.5 s of a 5 s window is 10% at worst, and less in practice, because the copy that runs just before the screen call leaves the tag nearly current.
- If the targets on screen need values current within 1 s, the 500 ms copy cycle meets that with a 2:1 margin.
Without the copy events, the display holds the stored value until the panel's first refresh after entry, and that interval depends on the link, so measure it on your own machine. With the events, the staleness is bounded at 500 ms by configuration, which is the difference between a number the user can act on and a flash of last cycle's data.
How do you prove the fix before operators rely on it?
Cycle the screens the way the machine does and watch three things at each transition: the PLC register, the internal tag and the display. Run it with one changed value and one unchanged value, so a match cannot pass just because old and new are equal.
Change one screen first and keep the rest of the project on the old tags until the test screen passes. Run the machine's real sequence a dozen times: finish, rest, summary screen, next cycle. On each entry, compare the register, the internal tag and the painted value, and note whether the old value flashes. If a display still shows stale numbers, confirm the event is enabled and that the display really reads the internal tag; checking the tag address first is the same walk-through to follow when a repointed display shows nothing at all.
Until the transition test passes on every value, treat that screen's numbers as unofficial wherever a user acts on them.
When is the PLC blank-and-zero sequence the better answer?
Only when a placeholder is acceptable on every affected value and nothing else is in place yet. Blanking and zeroing through PLC logic works, but the write, the screen call and the panel's refresh must land in a fixed order, which is timing-critical logic that breaks quietly.
Zero reads as a result. On a screen of averages and peaks, a zero can look like a measured value, and on totals it can look like a lost cycle. If you keep the PLC-side method, drive the blank and the zero from the same logic step that calls the screen, and run the transition test above across repeated cycles before you call it done. The event-manager copy needs none of that sequencing, which is why it is the first choice here.
Recommendation: use the event-manager copy to internal tags whenever an operator sees a screen for 10 seconds or less and the first paint matters, because the copy cycle bounds the staleness by configuration. Trial the hidden-object version on a single screen when you cannot add events, and keep the PLC blank-and-zero sequence only where a zero on screen is a value you accept.
Questions
Do trend and alarm records have the same stale-value problem?
No. Continuous monitoring paths, such as line trend objects and the alarm and event database, keep collecting regardless of which screen is active, so history belongs there. A numeric display is a snapshot of one tag at the moment the screen paints it. Treating that snapshot as a log is what makes the flash feel like lost data.
Does the copy event add much load to the panel-to-PLC link?
Each event reads one register every 500 ms, so six tags means 12 reads per second. On a serial link with spare capacity that is a small addition. On a link already near its limit, the first symptom is slower updates on other screens, so watch them during the trial and remove any copy event whose value nobody needs.
Does the PLC program need any change?
No. The PLC keeps writing its registers exactly as before, and the copy event only reads them. Machine logic, rest-period timing and the screen-call sequence stay untouched. That is the main reason to prefer this fix over PLC-side blanking: one project change on the panel, plus the display objects repointed.
What if a value must be newer than half a second?
SYS CLOCK500MS is the clock tag the documented setup uses as the trigger. Panel families usually list faster system clocks alongside it, so check the panel's help for a shorter tick and use that tag as the event trigger. The event structure stays the same; only the trigger tag changes.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.