A PLC-driven screen switch fires on a change of value, so the second write of the same screen number is ignored. Write the target screen number, wait out the transition, then clear the register to an unused value such as 999; size the clear delay at twice the measured worst-case transition, 3 s to start.
A fault happens, the PLC writes the faults screen number to the panel, and the screen switches. The next fault writes the same number and nothing moves. That is not a broken panel; it is how a PLC-to-panel screen switch works: it acts on a change of value, so a register that already holds the target number produces no new switch. The fix is a three-step sequence in the PLC: write the target screen number, give the panel time to draw it, then write an unused value such as 999 to clear the request. This article shows where the register lives in the panel project, how to size the clear delay from a transition you measure on the running machine, and how to commission the jump so it works on the tenth fault as well as the first.
Why does the PLC screen switch work once and then stop?
The panel switches screens on a change of value in the switch register, so a second write of the same screen number is not a new command and the panel ignores it; the fix is to clear the register to an unused number such as 999 between requests.
The switch register behaves like an edge input. The panel compares the word it polled last cycle with the word it sees now, and the difference is what launches the screen change; an unchanged value is a no-op no matter which screen it names. That is the same edge logic as an R_TRIG pulse that never shows on the HMI screen: a signal holding its state fires once and then stays silent. One current HMI platform documents the identical principle as an event on a tag, where the configured action runs when the tag's value changes.
Two consequences matter on the floor. Rewriting 24 while the register still holds 24 cannot reopen screen 24, however many times the fault bit pulses. And navigating with the panel's own buttons changes the screen while leaving the register untouched, so the PLC's idea of where the operator is can drift from the truth until the clear lands.
Where does the PLC write the screen number?
The PLC writes a plain 16-bit word in its own data area, and the HMI project binds that word to the switch: in the documented example the item is Switch to Screen Number (word), under SETUP > Project Attributes on the PLC to Panel tab.
Open the panel project's attributes and find the PLC-to-panel area. In the panel software that example comes from, the path is SETUP > Project Attributes, the tab is PLC to Panel, and the item reads Switch to Screen Number (word). Another maker's manual documents the same function in its system data area as a change-to screen number one word long, so expect the same shape anywhere: a single 16-bit integer word mapped to an address the PLC and the panel both know. A word carries 16 bits, so the working range tops out at 65535 unsigned or 32767 signed, and 999 fits either with room to spare.
Assign a word the PLC program already owns; the documented examples use V2000, a V-memory address, or N7:0, an integer-file address. The one requirement is agreement: the PLC logic must write the exact word the project binds to the switch, or the panel watches a register nobody writes. Confirm the mapping on both sides before you write any sequence logic.
How do I clear the register so the same jump can fire again?
Write the target screen number, let the panel finish the transition, then write an unused number such as 999 to the same register; set the clear delay to at least twice the worst-case transition you measure on the machine, and 3 s is a sound starting point.
Three rungs do it:
- On the fault condition, move the target screen number into the switch register.
- Start a timer whose preset comes from the machine: measure the worst case from the PLC write to the finished screen draw, and set the clear delay to at least twice that measurement.
- When the timer finishes, move the clear value into the same register.
Pick a clear value that names no screen in the project. 999 is the documented example because few projects ever number a screen 999, and any value above your highest screen works as well. Writing the clear value commands no screen; it only arms the register, so the next fault can move the target number in as a fresh change of value. Keep the timer inside the PLC sequence so every automatic request carries its own clear with it.
Example: how does a 25-screen project jump to its faults screen twice?
Example: screens 1 to 25 are valid, 999 sits outside that range and inside a 16-bit word's 0 to 65535, the measured 1.2 s transition sets the clear delay at 2.4 s rounded to 3 s, and the same jump can fire again every 4.2 s.
Take a packaging machine with 25 screens numbered 1 to 25, where screen 24 is the faults page and the switch register is bound to the integer-file word N7:0.
Check the clear value first. Valid screens run 1 to 25, so 999 names no screen, and a 16-bit word carries 0 to 65535 unsigned, so the move instruction cannot overflow.
Time the sequence next. Trigger a real fault and time from the PLC write to the finished faults screen; suppose the worst case on this machine measures 1.2 s. Twice that is 2.4 s, so set the clear timer to 3 s and keep the 0.6 s margin.
The sequence then runs on its own: fault bit on, 24 into N7:0, panel draws screen 24 within 1.2 s, and at 3 s the PLC writes 999. The earliest a repeat can arrive is 3 s clear plus 1.2 s draw, about 4.2 s after the first request, and a fault recurring at that pace still finds the register at 999 and switches again. Result: the jump fires on every occurrence and the register never rests on 24.
What symptoms point at the register, and what points elsewhere?
Match the symptom to the layer before changing logic: a register stuck at the target number means a swallowed repeat, a register that changes with no screen change means the project is bound to a different word, and a register reading 0 means the switch item was never assigned.
- The register sits at the target number after a repeat request and the screen stays put. The clear step never ran, or ran behind a fault condition that never dropped. Place the timer after the request and let it run unconditionally.
- The register changes and the screen never moves. The project is bound to a different word, or the PLC-to-panel link is down. Check the address on both sides and the link status before touching any logic.
- The register reads 0 while the PLC writes its number. The switch item was never assigned an address in the loaded project, or an older project is running on the panel.
- The screen switches, then snaps somewhere else on its own. Two instructions in the PLC write the same word, or a leftover timer from an earlier request fires mid-sequence. Search the program for every move to that address.
How do I test the screen switch on the running machine?
Trigger the jump twice from the machine's real fault condition and watch the register through both cycles; a sequence that only works when fired from the project editor has not been commissioned, because the operator may have moved to another screen between the two faults.
- Watch the register live through a full cycle: target number on request, clear value 3 s later. A register that rests on the target means the sequence is incomplete.
- Between two faults, walk the operator to another screen with the panel's own buttons, then fire again. The jump must still work, because the clear restored the register.
- Fire the same fault twice inside the clear window. Gate the second write on the register holding the clear value, and the second request queues until the first has cleared.
- Run the tests on the link the machine actually uses. Commission on the slower one, serial or Ethernet, and re-measure the transition there.
- Leave the operator's manual navigation untouched. An automatic jump is an information aid, and it must never be the only way back.
Keep a hardwired stop within reach of the screen: an operator who must wait for a screen change before reaching stop is a hazard you built yourself.
What else breaks when the PLC and the operator both drive the screen?
Two things bite when the PLC and the operator both drive the screen: the register can hold a stale target while the operator has moved on, and a pushbutton whose visibility bit is also its command bit can vanish before its release reaches the PLC.
Manual navigation is the benign case: the buttons change the screen, the register keeps its value, and the clear timer puts it back at 999 wherever the operator wanders, so the next PLC write always finds an armed register.
The pushbutton case is the one that bites. If one PLC bit drives both a button's visibility and its command, pressing the button can reset the condition, hide the button, and drop its release before the panel reports it to the PLC. Put the visibility condition on a separate tag from the command bit, and hold the button visible about 0.5 s after the press so the panel completes the exchange; treat 0.5 s as a starting point and re-test with rapid repeated presses on your hardware. For how manual navigation behaves once screens change under the operator, see fixing HMI function key screen navigation across screens.
When is a separate fault screen a better answer than a PLC-driven jump?
If the faults page outgrows the operator panel, put it on its own screen: a separate status board frees panel space, and small Android signage units can carry it, though they are not HMIs and take no video input from the PLC.
A standalone board also gives the faults page room the panel lacks: full fault list, alarm history, shift counts. We build small Android signage displays for exactly that duty, playing offline playlists or your own Android app when the board must show live values; the operator panel keeps its job and the board repeats the story at the end of the line. For where a small screen earns its place on a fault board, see the andon board guide. If the fault only needs a banner, a pop-up screen window shows it without stealing the working screen.
Recommendation: Write the target screen number, then clear the switch register to an unused value such as 999, with the clear delay set to twice the worst-case transition you measured on the machine, 3 s to start; gate every new write on the register holding the clear value. Move the faults page onto its own board only when it outgrows the operator panel, and keep the hardwired stop where it is.
Questions
Can two faults request two different screens?
Yes. Write each fault's own screen number and clear to 999 exactly as before; the panel only needs every request to be a change of value. When two faults fire close together, gate the second write on the register holding 999, or let the higher-priority number overwrite and accept one screen for both, then let the operator drill down from the faults page.
What if 999 is a valid screen number in my project?
Pick a value your screens never use. With 25 screens numbered 1 to 25, any value 26 to 65535 works in a 16-bit word; if the driver treats the word as signed, stay at or below 32767. If the numbering is so dense that nothing is free, renumber one screen, or trigger the jump from a change-of-value event on the tag instead of from the register's value.
Does the clear delay change between serial and Ethernet links?
The sequence is identical; only the response time moves. A serial link polls slower than Ethernet, so the same write can take longer to arrive and the transition can stretch past the 1.2 s you measured earlier. Commission the clear delay on the link the machine actually runs, and keep the twice-the-transition rule when you re-measure.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.