Many HMI editors offer a previous-screen destination beside the start-up and specific-screen choices; others handle returns with back and forward objects or navigation history settings. Set it on the shared overview screen and one Back button returns every operator to the screen they came from. Map each route into the screen first, and give start-up or PLC-called routes fixed destinations.
Yes. Set the screen-change object's destination to the previous screen option, and one Back button on a shared screen returns every operator to the screen they opened it from. An operator who came from screen 6 goes back to screen 6; an operator who came from screen 14 goes back to screen 14, from the same button. The trap is in the wording: the option means the screen visited immediately before the current one, not the screen with the next lower number. Map the routes into the screen, set the destination, and test every route on the panel before release.
What the previous screen destination does
A screen-change object takes a destination, and editors that offer a previous-screen choice usually list it beside two others: the start-up screen and one specific screen. Wording varies by package. Where the option is absent, the same return is handled through separate back and forward button objects or through navigation history settings.
The destination reads the runtime's record of visited screens. Previous means the screen opened immediately before the current one, whatever its number: a panel on screen 20 that was opened from screen 6 returns to screen 6, and the same screen opened from screen 14 returns to screen 14. Nothing in the project changes between those two visits, which is why one button covers every route.
Every screen change lands in that record, pressed or triggered. A jump triggered by the PLC and an idle return to the home screen after 10 minutes both count as visits, and both shape what Back returns to.
What you need
- Editor access to the project file.
- The list of screens that open the shared screen, including the start-up screen and any PLC-driven jumps.
- The panel itself, or a runtime on the bench, for the route test.
- Your normal change-control path for saving and transferring the project.
Set the back button
- Open the shared screen in the editor. If screen-change objects are new to you, the base setup is in HMI screen navigation with change screen buttons.
- Place the screen-change object, or select the existing one, and label it Back.
- Open the object's destination settings and choose the previous screen option. Leave the start-up screen and the specific screen choices as they are.
- Save the project and transfer it to the panel through your normal change control.
- Run the route test below, one route at a time.
Map every route into the screen first
The return is only correct when the visited-before screen is the one the operator should get, so write down every way the screen opens:
- From each entry screen. Confirm each of those buttons targets the same shared screen.
- At start-up. A panel that opens on the shared screen directly has nothing visited before it, so that route needs its own fixed-destination button.
- From logic. A screen the PLC calls into follows its own rules; change HMI screens from the PLC and give control back covers that case, and a route like that deserves a fixed return too.
Where a route should offer no return at all, check whether your editor can lock a screen-change button.
Example: ten recipe screens and one overview
A blending plant runs ten recipe-entry screens, Recipe 1 through Recipe 10, each with a button to one shared overview screen that lists every batch. There is no room on the overview for ten return buttons.
With mirrors, one copy of the overview per entry screen, each copy carries its own fixed back button: 10 copies of every object on the screen. A one-line change to the alarm banner becomes 1 edit × 10 copies = 10 edits and 10 transfers to the panel, and one missed copy leaves two screens showing different data for the same line.
With the previous screen destination: 1 shared screen and 1 Back button. The routes to verify are 10 entry screens + 1 start-up path that can open the overview before any entry screen was visited = 11 panel tests. Budget about 30 seconds per route on the bench, so the full sweep takes roughly 6 minutes. Each test is 3 actions: open the entry screen, open the overview, press Back. The operator from Recipe 3 lands on Recipe 3, the operator from Recipe 7 lands on Recipe 7, and the start-up path keeps its fixed-destination button. The shared screen wins once the 11 routes pass.
How to check it worked
For each route on your list, open the entry screen on the panel, press its overview button, press Back, and confirm the panel shows the entry screen you started from. Before each transfer, check the label reads Back and the destination setting holds the previous screen option, not a screen number. The example's plan is 11 routes; a job with 2 entry screens is 3.
If a route lands somewhere unexpected, stop the release, give that route a fixed destination, and repeat the panel test for every route before it reaches production. The editor save checks the project; the panel test checks the routes.
When to keep a fixed destination
Use the specific screen destination when the operator must always land in the same place: a screen that doubles as the start-up screen, a screen the PLC calls into, or a return path maintenance depends on. The previous screen choice earns its keep exactly where the source screen changes from visit to visit.
Keep mirrors out unless two entry routes genuinely need different overview content. Copies multiply the edit count and drift after later changes; one shared screen holds one set of line data.
Recommendation: Set one screen-change object to the previous screen destination on a shared screen that opens only from known entry screens, verify every route on the panel before release, and give start-up and PLC-called routes their own fixed-destination buttons.
Questions
What happens when the operator presses the back button twice?
The first press returns one step. A second press follows the same rule again and goes to the screen visited before that one, provided the runtime records each hop. Runtimes that keep a navigation history document how it is stored and shown, and some offer flat and nested recording modes in the runtime settings. If a project relies on pressing Back more than once, test the whole hop sequence on the panel before release.
Why not make one copy of the overview screen for each entry screen?
Copies duplicate every object on the screen, so one edit becomes ten edits and ten transfers. The copies also drift apart after later changes, and each copy carries its own return button to check at every release. A single shared screen with the previous screen destination keeps one set of objects and one button, and the return still lands on the entry screen the operator started from.
What if the previous screen option is missing from the destination list?
Some packages handle returns through separate back and forward button objects or through navigation history settings instead of a choice on the screen-change object. Use the mechanism your editor documents and keep the same rule: test every route on the panel before release. Do not substitute a specific screen number chosen to look like a return; it breaks the moment a second entry route exists.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.