A PLC chooses the HMI panel's screen by writing one integer selector register instead of one coil per screen. The panel switches when the value changes to a number mapped to a configured screen, rewriting the same number does nothing, and a nonzero number with no screen releases the display to the operator. The article gives the setup steps, the value table, and the reclaim hold time worked out in milliseconds.
Hand the screen choice to the PLC and the panel stops being a wall of buttons the operator must babysit. The clean way is one integer selector register in the PLC, one number per screen, written to the address the panel watches. Two documented behaviors make the whole design work: the panel only reacts when that value changes, and a nonzero value that matches no configured screen releases the display for manual use. This page sets up the register, maps the values, sequences the reclaim when an operator has navigated away, and runs the checks that prove the mapping before the panel goes into service.
Why use one register instead of a coil per screen?
Use one integer selector register: six screens need one number written per change, against six coils with interlocks, and the register gives the PLC a clean release state and a reclaim path a coil scheme must improvise.
A coil per screen looks natural: one bit per mode, bit on, screen shown. The panel's own mechanism is numeric, so a coil scheme either drives a screen-change function per bit or rebuilds the number in logic anyway. That doubles the bookkeeping: every new screen adds a bit, an interlock against the others, and an edge condition. Overlapping requests need a priority network spread across bits, and there is no natural way to hand the display to the operator, because dropping all coils is itself a signal the logic must interpret.
| Design question | One coil per screen | One selector register |
|---|---|---|
| Adding a screen | New bit, interlocks, edge logic | One more number in the map |
| Overlapping requests | Priority network across bits | One priority rung on one value |
| Handing display to operator | All bits must drop, meaning unclear | Write one value assigned to no screen |
| Reclaiming a screen the operator left | Per-coil edge tricks | Two writes and one hold on the same register |
How does the panel know the PLC asked?
The panel switches screens when the value at the selector address changes: a new number is an event, the same number again is nothing, and that is also why the operator can navigate freely between PLC requests.
This is the documented mechanism. One widely used panel line's configuration attaches a screen-selection function named ActivateScreenByNumber to the "Value change" event of the "Screen number" tag: the value changes, the panel activates the screen carrying that number. Search your own project's manual for screen selection by number bound to an on-change or value-change event; it is a standard pattern.
If your software has no value-change event, use the screen-selection object most packages offer: one entry per screen, each entry writing its own set value to the selector, with an illegal entry able to raise an error bit at an address you assign. The panel side stays the same; only the writing side changes.
The write itself is an ordinary register move: Write a screen number from a PLC to the panel register covers the addressing and the write path. What this page adds is the behavior around the number: the event, the release and the reclaim.
Which selector values mean what?
Map three value classes and nothing else: a changed number that matches a screen switches to it, a rewritten number does nothing, and a nonzero number with no screen releases the display for manual navigation.
| Selector value | What the panel does | What you use it for |
|---|---|---|
| Changed value with a screen behind it | Switches to that screen | Every normal PLC command |
| Same value written again | No event; the screen stays wherever the operator left it | Nothing; the operator keeps the display |
| Value above the screen count, assigned to nothing | Releases the display for manual navigation | Handover at end of cycle; first write of a reclaim |
| 0 | On the panel this pattern was documented on, the display went back to the previous screen | Test it once in your project, record the result, then decide |
Keep the selector off the safety path: a released display can be sitting on any screen, so a stop, reset or bypass must never live only behind a screen change.
What do you set up, in order?
Set up four things and the panel follows the PLC from commissioning on: one selector register, a value-change event bound to screen selection, one published number map, and PLC logic with a single owner of that register. You need access to the panel project, the PLC program, the screen list, and a monitor window that can watch the selector live.
- Pick the register. One integer register in the PLC, one owner: any rung that needs a screen change moves a number into it, and nothing else writes it. A second controller that wants a say sends its request to the owner.
- Bind the event. In the panel project, create the selector tag and attach the screen-selection function to its value-change event. One panel line documents the configuration as the "Activate Screen By Number" function, listed as ActivateScreenByNumber, on the "Value change" event of the "Screen number" tag.
- Publish the map. One table, the same numbers in the PLC rung comments: 1 Run overview, 2 Batch settings, 3 Alarms, 4 Trend, 5 Manual jog, 6 Maintenance.
- Reserve the release value. One number above the highest screen, 99 for the six-screen map, assigned to no screen, ever.
- Write the request logic. A new request that differs from the current selector value goes straight in. A request that equals the current value runs the reclaim from the next section.
- Download both sides. Then run the checks in the verification section below before operators get the panel.
What does a full example look like on a packaging line?
On a six-screen filler line, reclaiming screen 2 takes two writes and one hold: the PLC moves the release value 99 into the selector, holds it past one panel update period, 110 ms in this example, then writes 2 again.
The line runs the map from the setup section. The PLC writes 2 at cycle start so the operator lands on batch settings. Mid-run the operator opens the trend, screen 4. At the next cycle start the request is still 2 and the selector still holds 2, so writing 2 again creates no change and the operator stays on the trend. The reclaim:
- Move 99 into the selector. The panel sees the change and releases the display.
- Hold 99 long enough that at least one panel update lands inside the window.
- Move 2 back in. The panel sees the second change and switches to batch settings.
The hold is the step that gets skipped. Take two example values, a PLC scan of 10 ms and a project that polls the PLC every 100 ms; read your own from the project's communication settings. Back-to-back writes sit 10 ms apart, well inside one poll period, so the panel can sample after both and read 2 where it already had 2: no event, reclaim failed. A 200 ms hold settles it: 200 ms is more than one poll period plus one scan, 100 + 10 = 110 ms, so at least one sample falls inside the 99 window and the panel records both events. The rule to carry into any project: hold the release value for at least one poll period plus one scan, and program the next standard timer size above that.
The rung order and the edge cases of the sequence itself are covered in PLC to panel screen switch register: retrigger the same screen; the arithmetic above is what sets its hold time.
How do you prove the mapping before operators use the panel?
Run five checks from the PLC side and the mapping is ready for operators: every mapped number lands on its screen, a repeat changes nothing, the release value frees the display, the reclaim returns it, and zero's behavior is on record. Work from a monitor window or a test rung before the panel goes into service.
- Write each screen number, 1 to 6, and confirm the matching screen appears every time.
- Navigate somewhere manually, then rewrite the selector with the value it already holds and confirm nothing changes. That result is correct, and it is the same behavior that lets operators work undisturbed.
- Write the release value and confirm no screen error appears and the display is free for manual navigation.
- Run the reclaim: leave the display on a screen the operator chose, write 99, hold 200 ms, write 2. Batch settings should appear within about 300 ms, one 200 ms hold plus one 100 ms poll.
- Write 0, watch what the panel does, and record the result in the project notes. Let production logic rely on it only after you have seen it.
Then freeze the map: screen numbers, release value and register owner go into the project printout, so nobody assigns a new screen to the release value next year.
When is a coil per screen still the right choice?
Keep coils when a working program already speaks in bits: convert each active request bit to its screen number through one priority rung and leave the rest of the program untouched.
New project, screens follow the machine state: selector register, set up as above.
Existing coil logic that works: keep the coils, add one rung that converts the active request bit to its screen number, and give overlapping requests a fixed priority, alarm over manual over overview. The housekeeping a coil scheme needs is its own subject: Clear a PLC coil range when the HMI returns to a screen covers the cleanup side.
Bits upstream, numbers wanted at the panel: the converting rung is the bridge; keep the priority in one rung, not scattered across the program.
Recommendation: For a new project, run every screen change through one integer selector register owned by one rung network, bind the panel's value-change event to it, reserve one value above the screen count as the release and reclaim state, and hold that value for at least one poll period plus one scan before writing the target number. Keep coil-per-screen logic only where a working program already supplies the bits, and convert it with one priority rung.
Questions
What happens if two controllers both write the selector register?
The panel follows whichever controller wrote last, so give one controller ownership of the register. A second controller that needs a screen change sets a request code in a handshake register, the owner moves the matching screen number into the selector, then clears the request. If two controllers must write the selector directly, split the range between them, for example screens 1 to 3 to one and 4 to 6 to the other, so their values never collide.
How large should the release value be?
Pick a number above any screen you will ever configure: 99 for a project with 6 screens, 999 for one with 40. Keep it identical on both sides, in the panel project and in the PLC rung comments, so a screen is never assigned to it by accident. If your software's screen-selection object supports an illegal-value error bit, wire that bit into an alarm; it catches an accidental reuse the day someone adds screen 99.
Why did the panel ignore a screen number the PLC wrote?
Check two things in order. First the value: if the selector already held that number, the write created no change event and the panel stays where the operator left it. Second the timing: a reclaim written so fast that the release value and the target land inside one poll period can leave nothing for the panel to observe. Watch the selector live from a monitor window while the rung fires and the failed step shows immediately.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.