A panel exposes a current screen number and a screen change command to the PLC only where the HMI project defines a path for them; in this panel family that path is the documented PLC control object. Map it as the software prints, download, then prove the reading with a walk through known screens and one write to a noncritical screen before any logic depends on the value.
There is no screen register number you can copy from a table and trust. A panel exposes its current screen to the PLC only where the HMI project defines it, and the same project defines the command that lets the PLC change screens. The documented feature for the PLC-facing side of the screen in this panel family's software is the PLC control object: you place it on a screen from the object list, assign its PLC tag, and the software prints the address, data type and direction it uses. Configure that mapping, download the project, and prove it against known screens before any logic depends on the value. The symptoms, checks, worked example and fix are below.
Why there is no universal screen register
The screen number you see in the programming software is a project identifier, not a PLC address, and a tag with a plausible name does not prove the panel reads or writes it. The path from panel to PLC exists only where the project builds one: the project selects the driver and the communication path, and the PLC-facing screen value must be placed and mapped before the PLC sees anything.
Two jobs live in that path. A current screen value reports which screen is displayed. A screen change command requests a move to a screen. The software prints whether one tag carries both or each has its own address and data type; record what it prints, because the two jobs fail in different ways. Writing to a guessed address is a write to an unknown destination, so the fix below configures the documented path first.
What the PLC sees and what each symptom points to
- Every value from the panel is frozen. Known-good tags stopped updating too, so the link is down: driver, cable, node address, or power to the panel. Screen logic cannot repair a dead data path, so fix the link first.
- Other values update but the screen value holds one number. The screen mapping is missing from the project the panel is running, usually because the object was added after the last download. Add it and download again.
- The value changes but never matches the screen on display. The mapping, the data type, or the identifiers you assumed are wrong. Compare the raw values with the identifiers in the project's screen list; screen three in a list can carry identifier 30, so never assume the numbers run 0, 1, 2.
- A write from the PLC changes nothing. The command side is not configured, the value encoding does not match, or the write landed on the status tag. Confirm the mapping the software prints, including any separate trigger, before writing again.
- The panel jumps back to a screen nobody selected. Logic is writing the command on every scan and overriding operator navigation. Turn the write into a one-shot on the event and re-check the status value after each move.
Checks to run before you touch screen logic
- Read the project back from the panel before you edit it, so you are working on the program that actually runs; the article on reading an HMI project from the panel before editing shows how.
- Confirm the driver and communication path the project uses match the PLC you are watching.
- Open the panel's communication diagnostics and compare two known-good values against the PLC. If those match, the link is healthy and the screen mapping is the open question.
- Look for the screen status and command mapping in the project and record the address, data type and direction exactly as the software prints them.
- If the mapping is missing, add the PLC control object on a screen, assign its tag, and note what the software shows before you download.
- Note the scan time of the logic that will read the value; a typical scan is under 100 ms, so the status tag should refresh at least that fast once the mapping is live.
Example: proving a screen register on a three-screen panel
The names and numbers here carry the example; they are not defaults your software will print. A bench panel runs a project with three screens: the run screen carries identifier 12, the recipe screen 30, and the maintenance screen 41. The software maps the status value the panel writes to a 16-bit unsigned integer tag, SCREEN_NOW in this example, initial value 0, and the command the PLC writes to a 16-bit unsigned integer tag, SCREEN_CMD, initial value 0.
Read test. An operator walks the panel from the run screen to recipes, then to maintenance, then back to the run screen, pausing 15 seconds on each screen while you watch SCREEN_NOW in the PLC. The value reads 12 while the run screen is up, 30 after the move to recipes, 41 on maintenance, and 12 after the return: three moves, three matches, 3 for 3, inside a walk of about 1 minute. That is the proof the status path works for every screen you walked. If SCREEN_NOW had held one value through the whole walk, the status mapping is not in the downloaded project. If it had changed but disagreed with the screen on display, compare the raw values with the project's screen list before writing any logic.
Write test. With the bench idle and the operator told, write 30 to SCREEN_CMD. The panel moves to the recipe screen and SCREEN_NOW then reads 30. Have the operator touch back to the run screen: SCREEN_NOW follows to 12. That last step matters, because it shows the PLC write acted as a one-time request and nothing in your logic keeps rewriting the command. Test screen changes on a screen that hides nothing the operator needs, and never while the machine is being set up or adjusted.
From here the mapping is trusted for the three screens you tested, and only those. Re-run the walk after any download that touches screens or tags.
Change screens from the PLC without fighting the operator
Write the command once, on the event that calls for the screen, not on every scan. Logic that keeps rewriting the command takes the panel away from the operator each time they navigate, and the symptom list above shows what that looks like from the PLC. Two details catch most people on the second attempt:
- If the panel is already on the screen you are requesting, a repeat of the same number may need a retrigger to take effect; our article on the PLC to panel screen switch register covers retriggering the same screen.
- Once your one event has landed, the screen is the operator's call again. The handback, including how to give control back after a PLC-driven change, is covered in our article on changing HMI screens from the PLC and giving control back.
If the PLC also needs to act on the screen number, keep that logic to display decisions. Running PLC logic on the HMI current screen number tag is for choosing what the panel shows, not for stepping the machine; our article on that tag draws the line and shows why.
The fix and the record you leave behind
The fix is configuration, not discovery. Place the documented PLC control object in the project, map it exactly as the software prints, download through your plant's normal change process, then run the proof again: the screen walk for the status side and one write to a noncritical screen for the command side. If your project's documentation offers no way to configure the mapping, treat the current screen as unknown to the PLC and leave screen changes at the panel.
Recommendation: skip the address hunt. Add the PLC control object, map it as printed, and prove it with a three-screen walk plus one write to a noncritical screen before any logic depends on the value. Record the address, data type, direction and the identifiers you verified in the project notes, so the next engineer inherits a mapping instead of hunting for a universal register number that never existed.
A floor board is a different screen
If the goal is a board the whole cell can read, mirroring machine state for people standing away from the panel, that is a separate screen running its own playback, not a second HMI. We build shop-floor signage displays for that job: your own content, played offline, with the panel staying the operator's screen and the board carrying the numbers.
Questions
Can two panels share one screen register in the PLC?
Each panel carries its own project and its own mapping, so give every panel its own tags and test each panel separately. Sharing one command tag between panels means a single write moves both screens at once, which is rarely the behavior you want. If both panels must show the same screen, write both command tags from the same one-shot event and confirm each panel's status value follows on its own.
What if my panel's software has no PLC control object?
Then the project has no documented path for the job, and the current screen stays unknown to the PLC. Some packages expose a list of system values instead; if your documentation shows one for the current screen, map it, download, and run the same walk test. Never write to a guessed address to force the issue, because an unverified write lands on whatever data really occupies that location.
Does the screen value still mean anything after a power cut?
The project sets the screen the panel opens on when power returns, so read the status value fresh once the panel is back up and displaying. Do not act on the value you stored before the outage. If your logic latched a command that never landed, clear it on restart so the panel does not jump to a screen the operator did not choose.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.