Two HMI panels change together: separate the PLC registers

Why does a screen change on one HMI panel change the other panel too?

Both projects point at the same two PLC registers. One holds the panel's current screen number and one carries the screen command. A write from either panel or from the PLC reaches both displays, and two panels on one PLC behave as one display.

Each panel keeps its own picture of the plant only while those two addresses differ. The project reads its current screen number to know what it is showing, and it writes its screen command to jump. The PLC can write the command to drive a change from logic, and it can read the current screen number to interlock on what the operator is watching. Map both projects to one address and every one of those reads and writes lands in a single word: whichever panel or rung touches it last sets the screen for the whole room. Panel makers support several panels on one PLC as a normal arrangement, and the pattern sits behind most shop-floor screens and andon boards. The independence question lives in the data map, so that is where the fix goes.

What symptoms point to shared registers instead of a network problem?

The mirror travels through the PLC data table. The deciding symptom is a screen action on one panel that changes the other panel while both communications links stay healthy. A second Ethernet switch changes nothing, because both panels still read the same address.

• A tap on one panel moves the other panel's screen. The two projects share the current screen number register or the screen command register, and that shared pair is what this page separates.
• Only PLC-driven changes hit both panels. The PLC writes one command register and both projects watch it, so every logic-driven jump lands twice.
• Both panels show identical process values but keep their own screens. That is shared equipment data working as intended: two operators watching the same doors, valves or machines should see the same states.
• A screen freezes until someone taps it. Different fault, different page: start at why an HMI screen freezes until you tap it.

Swapping switches or patch cables leaves the coupling in place, because the shared address is the coupling.

How do you find the current screen number register in each HMI project?

Open the tag table in each HMI project and read the raw PLC address bound to the current-screen function. Those are the 2 addresses to compare, word for word, in both projects.

The current screen number tells the project and the PLC which screen is live. Every project stores it against a PLC address, and the label beside that address says whatever its author typed, so read the address field itself. Two different project names tell you nothing about two different addresses: a renamed copy keeps every address it inherited, and only an edited mapping moves one. If panel 2's current screen number address equals panel 1's, the panels share screen state and you have found half the coupling. Note the address, then search the PLC program for rungs that read it or write it. The PLC side of watching and forcing the active screen has its own page: monitor and change HMI screens from a PLC register.

How do you trace the screen command register and the logic that writes it?

The screen command register is the address a screen button or a PLC rung writes to force a screen change. List every write to it, because one shared command address delivers the same jump to every panel mapped to it.

The wiring has two halves. In the HMI project the switch hangs on a tag: the project watches the command tag and, on its value change, opens the numbered screen. In the PLC, logic writes a screen number into the register the project watches. That handshake, including the trick of re-triggering a screen the panel already shows, is its own page: write a screen number from a PLC to the panel register. Sort what you find into three cases:

• Same command address in both projects. Remap panel 2 to its own word and re-point every rung that targets it.
• Different command addresses, yet both panels still move together. The PLC writes both words or copies one value into both, so trace the rungs until you reach the shared source.
• No PLC write anywhere. The coupling sits on the current screen number side, so go back to the tag tables.

Keep the two roles apart while you diagnose: a command register remapped on its own leaves a shared current screen number tying the panels together.

Which PLC registers should the second panel get?

Give the second panel 2 unused words in the PLC data table, one for its current screen number and one for its screen command. Pick them so they overlap nothing else in the map. Panel 1 keeps its original 2 words and every process and equipment address stays shared.

A screen number is a small whole number, so one 16-bit word carries it with room to spare; that is why the whole fix takes 2 words per panel. Confirm a candidate word is free twice: search the PLC program for the address, then watch the live data table and accept the word only if it holds one steady value through a full shift of production. PLC programmers already know this rule from per-instance data: a reusable instruction block gets one tag per instance, and why each add-on instruction instance needs its own tag shows what two instances sharing one tag do to stored values. Splitting navigation leaves writable data shared: when both operators write the same setpoint register, the last write wins, and two HMIs writing to one PLC: who wins the write covers that race.

Recommendation: When two operators must navigate independently on one PLC, give each panel its own pair of registers, 2 words per panel, before anything else: verify each new word free in the program search and the live data table, re-point the PLC rungs that serve the second panel, and keep all shared equipment and process addresses exactly as they are.

What does an example register map for two panels look like?

Say a control room runs 2 panels on 1 PLC. Both projects map the current screen number to word 100 and the screen command to word 101. The panel 2 remap moves its 2 words to 110 and 111, and screen control grows from 2 words to 4.

The panel 2 project began as a renamed copy of the panel 1 project, so it still points at words 100 and 101. Operator 2 taps a screen-select button that writes 3 to word 101. Both projects watch word 101, so both panels open screen 3, and the same happens in reverse for every jump on either side.

Check the replacement words first: search the PLC program for 110 and 111, find no rung and no other reference, and watch the live data table through a shift with both words holding 0. Then rebind panel 2 and re-point its logic:

The arithmetic: 2 registers per panel times 2 panels is 4 words of screen-control data in total. Panel 1 owns words 100 to 101 and panel 2 owns words 110 to 111, so no word appears in both rows. Step each new block by 10 (100, 110, 120): a third panel then takes words 120 and 121 with no re-check of its neighbours.

Re-test the room. Operator 1 selects screen 3: panel 1 opens it and panel 2 stays where operator 2 left it. Operator 2 selects screen 5: panel 2 opens it and panel 1 holds. Four words, two independent stations.

How do you apply the remap without breaking shared equipment data?

Make the change with the doors and equipment under direct supervision, because a panel mid-download misses whatever commands arrive on it. Then touch only the 4 screen-control words, back up both projects first, and leave every shared equipment address alone.

1. Record the as-built addresses: panel 1's 2 words, panel 2's 2 words, and every rung that reads or writes them.
2. Confirm the replacement words are free with the program search and the full-shift live data watch from the section above.
3. Rebind panel 2's project: the current screen number, the screen command, every screen-select button and every value-change event that opens a screen.
4. Re-point the PLC logic: rungs that command panel 2 write its new command word, and rungs that interlock on panel 2's view read its new screen number word.
5. Download panel 2's project under your site's normal change process, confirm the link returns, and watch the new words move as panel 2 changes screens.

The split stops at screen control, because the requirement is independent navigation. A wholesale division of the data map breaks the common picture both operators need and buries the one shared pair that caused the fault: touch the 4 words and stop there.

How do you verify the two panels now navigate independently?

Test both directions with both panels online. A screen command from panel 1 must move panel 1 and leave panel 2 on its own screen, and the same command from panel 2 must leave panel 1 alone.

• Operator test, both directions: panel 1 selects a screen while panel 2 holds, then panel 2 selects a screen while panel 1 holds.
• PLC test, per panel: trigger panel 1's logic-driven screen change and panel 2's separately, and watch each panel follow its own command alone.
• Data watch: with the live table open, words 100 and 101 move with panel 1, words 110 and 111 move with panel 2, and the opposite pair stays static through every test.
• Shared picture intact: door states, alarms and process values still match on both panels, because both still read the same equipment addresses.

All four checks pass and the panels are independent, so clear them for service. If one direction still mirrors, the remaining path is the register you did not remap, and finishing that pair is the whole remaining job.

Questions