Add a second HMI panel on the same PLC tags safely

Same addresses, separate tag definitions

Every HMI project carries its own tag list. A tag is a name, an address in the controller and a data type, and the panel resolves it over the communications link on every update. Two projects can point at the same addresses without sharing anything: the controller never sees the tag names, only the reads and writes arriving on the wire.

So the question about needing its own tag database has a plain answer: the remote panel always has one. What you actually decide is which addresses both projects touch, and what happens when both touch one address for a write. Matching tag names in two projects coordinate nothing; arbitration is a design task in the controller logic, and the rest of this article builds it.

Reads are free, writes race

Process displays, indicator lamps and alarm lists only read. A second panel showing the same values and alarms costs the controller a little extra poll traffic and cannot disturb the program.

Writes behave badly in two documented ways.

Concurrent writes to one tag overwrite each other. A controller maker's support documentation states the case plainly: when two clients write the same tag, the data can be overwritten on the system side. Whichever write lands last is the value the machine runs on, and the order depends on poll timing and operator timing, never on intent. Two HMIs writing to one PLC: who wins the write works through that end state in detail.

A panel can also write before anyone touches it. Support documentation for one HMI platform records that its tags initialize to zero after a power-up and overwrite a retained controller value during startup. A new remote panel booting at the wrong moment can clear a retained setpoint with no operator involved. Step 8 closes that hole.

What you need

• The existing panel project and its programming software.
• Programming access to the controller, so you can add the arbitration logic.
• The remote panel hardware, with power and mounting sorted at its end of the line.
• A communications path both panels can use. Ethernet is the practical choice for this link and makes the next panel easier to add.
• Three spare controller bits per shared value, request, grant and done, plus one integer for the entry state.
• A test window with the line stopped.

Set up the second panel

1. Inventory every write-capable object. Open the existing project and list each numeric input, each pushbutton that writes a bit, and each alarm acknowledgment control. Acknowledgment counts as a write when the clear runs through the controller, because a latched alarm stays latched until something clears it. Mark each object read-only or writes.

2. Create the remote project with its own tags. Point the new tags at the same controller addresses the first project uses and match the data type at every one: a 16-bit tag aimed at a 32-bit value shows the wrong number and writes over only half of it. Give the far panel the process values, alarm states and statuses its operators need.

3. Set most objects display-only. On a typical process panel most screens are displays, and displays carry no risk. Leave the entry object off the remote project for any value only one end of the line changes; the panel that holds that write today keeps it.

4. Choose the write rule for the rest. Designated writer: one panel keeps the entry object and the other never gets one. Request-grant handshake: both panels carry the entry object and the controller admits one entry at a time. Values tied to one end of the line take the designated writer; values both ends must be able to change take the handshake.

5. Gate the designated entries with a controller bit. Drive each entry object's enable condition from a controller bit, so the panel shows the value but refuses entry until the bit is on. Let a PLC bit gate numeric entry with two HMI objects shows the two-object version of that gate.

6. Build the handshake for shared entries. The controller referees: the panel raises a request bit; the controller checks that no other request is live and the pending value is in range, then sets the grant bit; the panel writes only while the grant is on and raises done when the entry closes; the controller clears request and grant together. Give the controller a timeout, so a request with no done inside it frees the value; that timeout is what releases a panel that lost comms mid-entry. A comms cut also freezes the panel's display, and Stale HMI values after PLC comms loss: the per-PLC heartbeat fix covers the heartbeat pattern that keeps a dead link from showing live-looking numbers. Documented panel features carry this pattern: numeric keypads on one HMI family use notify and handshake tags, so the panel verifies the entered value reached the write tag before the keypad closes; another platform documents an automatic handshake where you assign the handshake tags and set a timeout, with no scripting on the panel side; and a popup keypad bit, on exactly while an operator is entering a value, can serve as the request.

7. Show the entry state on screen. Give the operator a visible indication driven by the controller bits: entry open, entry refused because another panel holds it, entry timed out. Gating a visible object on a controller bit is the mechanism Gate HMI button visibility on a PLC timer done bit applies to a timer bit, and it works the same with a grant bit.

8. Close the startup hole. List the tags in the remote project that write at startup and note where they point. Keep startup-writing tags off retained addresses, or set them to write on change only, so a panel booting up cannot clear a retained value before anyone touches the screen.

Worked example: two panels on a dryer line, one shared setpoint

The inputs, with where each comes from:

• The line: a 15 inch operator panel at one end of a long production line and a second panel at the other end, both talking to one controller over Ethernet. This is the case this article is written for.
• Shared operator-entered values in this example: one, the dryer temperature setpoint. Everything else on the far panel is display-only.
• The handshake: a request bit, a grant bit and a done bit in the controller, named here for the example; your project's tag names are your own.
• Panel update interval: 500 ms, an example value; take the real one from your project's update settings.
• Handshake timeout: 5 s, an example value you set in the handshake configuration.

The rule in words: the first request wins. A request raised while the grant is on is refused on screen. A request with no done inside the timeout is dropped and the value is freed.

The arithmetic: 5 s ÷ 500 ms per poll = 10 polls. A live request therefore survives nine missed polls before the controller times it out, so one lost poll cannot cancel a real entry, and an abandoned entry is freed within 5 s at most.

The result: operator A at the far panel taps the setpoint and the panel raises its request; the controller sets the grant; A enters 165 °F, done follows, the controller latches 165 °F and clears the handshake. While that grant is on, operator B at the near panel types 170 °F and raises the second request; the controller holds it off, B's screen shows that another panel is entering, and the dryer keeps running on 165 °F. Swap the order and the outcome swaps with it. One grant, one writer, same result whichever panel asks first.

The decision: with one or two shared values, build this handshake. With three or more, make the near panel the write station for everything and keep the far panel display-only; past a handful of entries the logic stops paying for its upkeep. Set the timeout at ten times the panel's update interval.

How to check it worked

Run the checks in this order, with the line in a safe state, so a wrong or conflicting value cannot actuate anything:

1. Value agreement. Change a test value from the near panel; the controller must receive it and the far panel must show the new number within one or two updates.

2. Simultaneous entry. Have both operators raise requests with different values, 165 °F and 170 °F as in the example. The loser's screen must refuse cleanly and the controller must keep the winner's value. Swap the panels' roles and repeat; the result must be the same whichever panel asks first.

3. Cancellation. Raise a request and cancel the keypad without writing. The grant must clear, and the next request must be accepted immediately.

4. Comms loss. Disconnect the link at the panel holding the grant mid-entry. The controller must drop the request inside the 5 s timeout and free the value for the other panel. Reconnect and confirm the panel recovers to current values.

5. Startup. Power-cycle the far panel while the line holds a retained value. The retained value must survive the panel's startup writes.

6. Release record. Write down which objects stay display-only and which panel or handshake may write each shared value, and keep the list with the project file.

Recommendation: Run the remote panel display-only by default and turn on writes only for values both ends of the line genuinely enter. With one or two shared values, build the request-grant handshake and set its timeout at ten times the panel's update interval. With three or more, make the original panel the write station for everything and skip the handshake. Run the checks above before an operator touches the new panel on a live line.

Questions