A panel driven by a screen-change tag acts on a change in the value, so the PLC's second write of the same screen number does nothing. Let a rung write an unused nonzero number back to the tag once the panel reports it has arrived, and every later write works.
A machine panel that changes screens from a PLC tag moves when the tag's value changes, and only then. Write screen 6 once and the panel goes to screen 6; write 6 again and the panel has no new request to act on, so the display stays wherever the operator left it. The totals reset still fires on every press because the reset logic and the screen-change edge are separate pieces of logic, which is why the fault looks like a bad panel when the sequence is the cause. The fix is to re-arm the tag: once the panel reports the screen it is showing, one rung writes an unused nonzero number back to the command tag, and every later write becomes a fresh change. The write basics are in writing a screen number from a PLC to the panel register; this page goes into the second write that never arrives.
Why does the panel ignore the second screen change from the PLC?
Because the panel triggers a screen change on a difference in the tag value, not on the value itself: a second write of the same screen number, such as 6 again, presents no difference, so there is no request for it to act on.
Tag-driven screen changes are a standard feature: the project binds a tag, and the panel watches it for movement. The panel compares each value it sees against the value it last acted on, and equal values give it nothing to do. That is why a manual edit of the value in the programming software's online memory editor appears to fix the machine. The edit is a change, so the panel acts once; the PLC's next repeated write fails again for the same reason.
Two values are in play, and they drift apart. The command tag is what the PLC writes to ask for a destination. The displayed screen is whatever the panel is showing now. Operator keys change the displayed screen without touching the command tag, so after the operator navigates away, the tag still holds the last destination and the next request repeats it. The same edge-versus-level distinction drives other floor faults: motion axes that jog again once servo-ready is restored are one example, an action that refires on a recycled edge condition.
What symptoms point to a stuck screen-change tag?
The pattern is a screen change that works once after any change to the tag value and then stops: totals reset on every press while the screen moves only on the first press, and the operator's keys keep working throughout.
Match what the machine does against this list:
- The screen moves on the first reset and stays put on the second: the command tag still holds the number of the screen it already reached.
- Totals reset on every press while the screen moves only once: the reset rung and the screen-change edge are independent, so the machine logic is healthy and the request sequence is the fault.
- A manual value edit in the programming software makes the next PLC write work exactly once: the panel responds to a changed value, which confirms the cause.
- Operator keys move the display but the PLC-directed return does nothing: the display moved without a write, so the command tag is stale compared with what is on screen.
- A second pushbutton added for the screen change seems to fix it: the extra path happens to present a changed value, while the original button keeps the same weakness.
Treat a memory-editor edit as a diagnostic step, never as the recovery procedure: it bypasses the production sequence and leaves the command tag unarmed for the next automatic cycle.
How do you watch the screen-change tag while the machine runs?
Watch two values online at the same time: the tag the PLC writes to command a screen and the value the panel publishes for the screen it is showing, then step the machine through one full reset cycle and record both after every action.
Work through these checks in order:
- Reproduce the sequence online. Start with the panel on a screen other than the command value, press the reset button, move away with the operator keys, press reset again, and record both values after every step.
- Find the panel's current-screen tag in the panel project's tag list. A panel that changes screens from a tag can also publish the number of the screen it is showing; use the configured tag, never a guessed address. Running PLC logic only on the HMI current screen number tag shows what that value is good for beyond this fault.
- Check the data type. The command tag and the current-screen tag should be the same integer type the project declares, so the PLC comparison reads both the same way.
- List every writer of the command tag. One owner should issue requests; a second rung that writes the tag silently overwrites a request or the sentinel.
How do you re-arm the tag so every screen change works?
Add one rung that compares the commanded screen number with the panel's current screen number and writes an unused nonzero value to the command tag whenever the two match, so the next write of the real destination is always a change the panel can act on.
Carry it out in this order:
- Choose the sentinel: one number that no configured screen uses and that is not 0, and reserve it for re-arming across the whole project.
- On the reset event, run the existing totals reset and write the destination screen number to the command tag.
- Place the re-arm rung after the command write in the scan: when the command tag equals the panel's current screen number, write the sentinel to the command tag.
- Because the re-arm rung sits after the write, a command to the screen already showing is re-armed in the same scan, so the sequence also holds when the operator never left the destination.
- Prove it on the machine: press reset, navigate away, press reset again, and confirm the panel lands on the destination both times.
The sequence in generic names, with illustrative values:
ScreenCommand : INT := 99 // illustrative name and sentinel value
CurrentScreen : INT // the panel's published current screen, read-only
ResetPulse : BOOL := FALSE // one scan on the reset pushbutton
IF ResetPulse THEN
ScreenCommand := 6 // destination screen in this example
END_IF
IF ScreenCommand = CurrentScreen THEN
ScreenCommand := 99 // re-arm; never write 0 here
END_IF
Use your project's tags and syntax; the two conditions and their order are what matter. If operators and the PLC both steer screens and the PLC has to take or hand back control cleanly, changing HMI screens from the PLC and handing control back covers that side of the handshake.
Why can't zero be the unused screen number?
On many panels zero is itself a command, a return to the previous screen, so writing it can move the display instead of quietly re-arming the tag; pick a value that no screen and no navigation function in the project uses.
Choose the sentinel from the project's own screen list, not from habit:
- List every configured screen number and every navigation function the project uses.
- Pick one value outside that list; in a project whose screens run 1 to 20, a value such as 99 is free.
- Test the sentinel once at changeover or with the machine stopped: write it manually and watch the panel. The right value produces no reaction, no move and no error screen.
- If the panel does react, the number is in use somewhere in the screen or navigation configuration; pick the next free value and test again.
Out-of-range numbers are handled differently across panel families, and one manual write tells you how yours treats the value you picked, before any rung relies on it.
What if the panel publishes no current screen number?
Use a timer as the fallback: command the destination, wait 2 seconds, then write the sentinel, and set the preset from the slowest transition you measure, not from a guess.
The 2-second value is a workable starting point where the slowest measured transition is near 1 second. Time the change from the PLC write to the visible screen, including right after power-up when communications are busiest, and set the preset above the slowest value you see; a measured 1-second worst case becomes a 2-second preset. Arm the timer with the command write, let it time out once, and write the sentinel on the done bit. A preset below the real transition time can overwrite the request before the panel acts on it, and the change is lost, so the measured slowest transition and the margin decide the number. When the trigger is an alarm bit instead of a pushbutton, the tag rules stay the same; event-triggered screen change on an HMI when a PLC alarm bit turns on covers the event side of that setup.
What does a working example look like?
A packing line uses screen 6 as its totals summary: after each reset the PLC writes 6 to the command tag, and the re-arm rung returns the tag to 99, a number no screen uses, once the panel's current screen reads 6.
Trace it in the table; the tag values are the whole story:
| Step | Command tag | Panel's current screen | Panel shows |
|---|---|---|---|
| Start of shift | 99 | 3 | Screen 3 |
| Reset press 1 | 99 → 6 → 99 | 6 | Screen 6 |
| Operator moves away | 99 | 2 | Screen 2 |
| Reset press 2 | 99 → 6 → 99 | 6 | Screen 6 |
Press 1 changes the tag from 99 to 6, a difference the panel acts on, and the compare rung then finds command equal to current screen and restores 99. The operator's move to screen 2 leaves the command tag untouched at 99. Press 2 writes 6 again, and because the tag sits at 99, the 99-to-6 step is a fresh request, so the panel moves. Every reset ends the same way: totals cleared, panel on screen 6, tag back at 99 and armed for the next request. Screen 6 and sentinel 99 are this example's values; any destination and any reserved nonzero sentinel behave the same way.
Recommendation: use the compare-and-re-arm rung whenever the panel publishes its current screen number: command the destination on the reset event, write one reserved nonzero sentinel whenever command equals current screen, and keep the 2-second timer fallback for panels with no current-screen value, with its preset set above the slowest transition you have measured, 2 seconds against a measured 1-second worst case. Never use 0.
This sequence belongs to the machine's own panel. If the line also needs a separate notice or status screen that plays your own content, that is a different choice, and shop-floor signage screens are where to look.
Questions
What data type should the screen-change tag use?
Use the integer type the panel project declares for its screen list, and declare the PLC tag to match, because the comparison rung reads both values and a mismatch reads wrong numbers instead of raising a fault. Keep the sentinel inside the same range as the screen numbers. If the project stores screen numbers as 16-bit integers, an INT tag in the PLC is the usual match; confirm the type in the panel project's tag list before you wire the comparison.
Does the re-arm write need to wait for the communications scan?
The panel publishes its current screen over the communications link, so the value can arrive a scan or two after the display has moved. The lag only delays the re-arm write; the command tag holds the destination until the re-arm fires, so a valid request stays valid. Run the comparison every scan and expect the sentinel to land a few scans after the transition.
Can two different PLC rungs both command screen changes?
Yes, but give them one tag and one sentinel so every request is a change from the sentinel to the destination. If rung A commands screen 4 and rung B commands screen 4 again, the second write fails exactly like the repeated reset write. Each rung can check that the command tag differs from its destination before writing, or both can share one re-arm rung that restores the sentinel between requests.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.