A Forward Screen button that does nothing is usually at a navigation-history boundary, not broken. The panel keeps the order in which screens were viewed and steps forward or backward through that order; with no route recorded there is nothing to step to. One direct screen change builds the history, then both buttons work.
The Forward Screen button is not broken, and the firmware does not need a reload. Forward Screen and its partner Previous Screen walk the history of screens the panel has already displayed. Right after startup that history holds exactly 1 entry, so nothing sits ahead of the current screen and nothing sits behind it, and a button that does nothing is the documented result. One direct screen change, made with an ordinary screen-change button, gives the pair a route to walk, and both buttons come alive. The two-screen test below settles it on the bench in about 5 minutes, and the lasting fix for operators who expect a true next screen is a fixed destination button on each screen, not a repair to the history buttons.
What the forward and previous screen buttons really do
The panel keeps an ordered list of the screens it has displayed, in the order they were viewed. Forward Screen steps up that list, 1 entry per press. Previous Screen steps down it, 1 entry per press. Documented behavior for these controls states the boundary rule in one line: at the highest screen in the viewed order the forward button does nothing, and at the lowest screen the previous button does nothing.
Two consequences follow. First, the pair needs a recorded route. A screen that exists in the project but has not been displayed this run is not in the list, so forward can never reach it. Second, the list records the route the operator walked, which can differ from the project's screen numbering. Open screen 1, then screen 9, then screen 2, and the list reads 1, 9, 2.
Other HMI lines document the same split. One runtime documents its system functions ChangeScreenNext and ChangeScreenPrevious alongside a navigation history setting, which puts the same history rule behind next and previous names.
Why both buttons are dead right after startup
At power-up the viewed list holds exactly 1 entry: the start screen. Nothing sits behind it and nothing sits ahead of it, so both buttons have nowhere to step. Because the simulator and the panel apply the same rule, the dead button looks identical in both places. That symmetry points to a rule of the runtime, not to a wiring, firmware or communications fault. Reloading firmware will not add an entry to a list of viewed screens, and a new PLC link setting will not either.
The dead period ends at the first screen change the project records, and the surest way to produce one is a direct button press. Some projects open screens from the PLC side, for example with an event triggered screen change when a PLC alarm bit turns on. Whether such a jump records an entry in the viewed list is not stated in every vendor's documentation, so include one alarm jump in the bench walk before operators rely on Forward Screen after one.
Symptoms and what each points to
| What you see | What it points to | Next check |
|---|---|---|
| Forward and Previous both dead immediately after startup, in simulation and on the panel | The viewed list holds only 1 screen, the start screen | Run the two-screen test below |
| Both buttons come alive after 1 direct screen change | The list gained a route, and the buttons were healthy all along | Confirm each button's direction with the walk in the scenario below |
| Forward dead while Previous works | You stand at the newest entry of the route | Step back with Previous, then press Forward from an earlier screen |
| Previous dead while Forward works | You stand at the oldest entry | Press Forward once, then try Previous again |
| Both still dead after a route you know you walked | The button object is probably not assigned to Forward Screen or Previous Screen | Open each button object, check the assigned function, and repeat the test from screen 1 |
| Direct screen changes fail as well | A separate fault in the screen-change object or the link | Check the object's target screen, then watch a live PLC value on a screen that shows one |
Run the two-screen test
- Pick 2 screens that already exist, or build a two-screen test project. Put 1 screen-change button on screen 1 that opens screen 2. Put a Forward Screen button and a Previous Screen button on both screens, where they are easy to reach.
- Start the simulator on screen 1. Press Forward Screen, then Previous Screen. Expect nothing from either press, and note it.
- Press the direct button to open screen 2. Press Previous Screen: screen 1 should come back. Press Forward Screen: screen 2 should come back.
- From screen 2, press Previous Screen twice. The first press lands on screen 1. The second does nothing, because screen 1 is the oldest entry in the route.
- Load the project to the panel and repeat the walk once, at a moment the line is not using the screen.
If both buttons come alive at step 3, the buttons, the objects and the runtime are healthy. The dead first presses were an empty history list doing what the runtime documentation says it does, and nothing in the project or the panel needs repair.
Scenario: three screens and one restart
A pump station panel carries screen 1, an overview; screen 2, a discharge detail; screen 3, an alarm list. The process walks them in numeric order.
Cold start. The panel opens screen 1, so the viewed list reads [1] and the position is entry 1 of 1. Forward Screen does nothing: no entry 2 exists yet. Previous Screen does nothing: no entry 0 exists.
The operator opens screen 2 with its detail button, then screen 3 with the alarm button. Each direct change appends 1 entry, so the list grows from [1] to [1, 2] to [1, 2, 3] over 2 presses, and the position moves to entry 3.
Backtrack. Previous from entry 3 steps 1 entry down to entry 2, screen 2. Previous again reaches entry 1, screen 1. A third Previous does nothing: entry 1 is the oldest. Replay. Forward from entry 1 steps to entry 2, then to entry 3. A third Forward does nothing: entry 3 is the newest. Every press moves the position by exactly 1 entry along the walked route, never by a screen number.
Restart. The list collapses to [1] again. Screen 3 still exists in the project, but forward cannot reach it this run, because no route has led there. 1 direct change, screen 1 to screen 2, restores a working route for Previous.
If operators need a true next screen and previous screen
History buttons replay a walked route. A fixed process sequence needs direct destinations. Give each screen a button that opens the next screen in the process, and the operator's path stops depending on the route they happened to walk to get there. Where one object should offer every destination, a screen selector list does the job, and the walkthrough on building an HMI text menu with a screen selector list shows the setup.
Check your installed software before redesigning. Many screen change pushbutton objects list fixed destination screens only and carry no next screen choice; open the object's option list and look before you assume. Where the object cannot do it, let the PLC drive the screen change, as covered in changing the HMI screen from the PLC and giving control back. Older PC-based HMI packages shipped without built-in history buttons at all, and integrators scripted the pair themselves; a knowledge-base walkthrough covers implementing forward and backward navigation buttons in a legacy PC-based HMI package.
Recommendation
Recommendation: Run the two-screen test before you reload firmware, replace a panel or touch the PLC link. If both buttons come alive after 1 direct screen change, the project needs no repair: keep Forward Screen and Previous Screen where operators genuinely backtrack through a walked route, and put a fixed next-screen button on every screen where the process defines the order. If the buttons stay dead after a route you know you walked, check the assigned function on each button object first. A correctly assigned pair that still refuses to step after a known route is a support case for the vendor, and the walk test hands the vendor the exact sequence to reproduce.
Questions
Does the forward screen button behave differently in simulation and on the panel?
No. Both apply the same history rule, which is why the dead button looks identical in the simulator and on the hardware. Run the two-screen test in simulation first, because edits and restarts are faster there, then load the project to the panel and repeat the walk once. If the results differ, the suspect is the loaded project or the object assignment; if they match, the history rule explains what you saw.
How many screens does the navigation history remember?
The maximum depth is not stated in the documentation consulted for this article, so treat the list as short and design so the number never matters. Give every screen a direct button to the screens operators actually need. If a long backtrack is part of the operating procedure, walk the entire route on the bench and watch for the point where the oldest entries stop being reachable.
Why did forward look like a next screen button in the first place?
Because the common screen change pushbutton object lists fixed destination screens and often carries no next screen choice, a button labelled Forward is the nearest thing on the palette. On a line where screens are visited in numeric order, replaying the route and stepping to the next screen give the same result, so the difference stays hidden until a cold start or a jump between screens exposes it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.