Tell which PLC lost communication on a multi-PLC HMI panel

Why does the panel show the same communication error for every PLC?

The panel raises that error for itself, once, whichever connection failed, so a panel watching 3 PLCs prints the identical code whether the north compressor, the south compressor or the filler stopped, and that code cannot name the failed device.

The error handler sits above the connections: it reports that at least one of them stopped answering, and nothing more. Per-device identity has to come from information you add to the project. Two things supply it. The device name you give each connection in the panel's communication setup, which the panel shows on its fault bar while that device is off. And one heartbeat tag per PLC, which each PLC keeps stepping while it is healthy. Everything else on this page builds on those two.

What are the symptoms and what does each one point to?

Four symptoms travel together on this fault: one identical error code for every PLC, a tag reset that leaves the display unchanged, text entry that stops accepting input, and a data column that freezes while its neighbors keep counting.

Read the symptoms this way:

• Same error code for every PLC. The fault is raised per panel. It says a connection failed, and nothing about which one. Identification has to come from the setup, not from the code.
• Reset triggered from the comm-fail tag leaves the display unchanged. The update path that trigger depends on is inactive while the fault stands. Move the reset to recovery, or into the PLC.
• Text entry into an internal tag rejected while a PLC is down. Writes from screen objects into internal tags are unavailable during a communications failure. Keep operator entry out of the recovery plan.
• One column of values frozen while the others keep updating. That column belongs to the failed connection. Its tags hold their last value or read as invalid, depending on how the driver treats a dead connection, so gate the column on that PLC's status tag.

How do I give each PLC a name the panel can show?

Open the panel software's communication setup, the screen one package reaches under Setup and then Panel Manager, and give each of the 3 connections its own device name, such as NORTH for the north compressor and SOUTH for the south compressor.

Panel manuals treat the device name as the unique name that identifies the device on the network, so name the equipment and not the position in the rack. The setup that matters:

1. Confirm one device entry per PLC, each pointing at its own IP address. Two entries on one IP address fail together and make both names worthless.
2. Rename each entry after its equipment. An operator reads NORTH at a glance; 'PLC 2' means nothing at 3 a.m.
3. Transfer the project to the panel.
4. Switch one PLC off. The bar that comes across the screen should carry that device's name. Restore it, and repeat for the other two.

If the bar shows a generic name after a rename, the usual cause is two entries pointing at one IP address.

Naming is also what makes per-device tags usable; pointing one HMI panel at four PLCs with per-device tags shows the tag layout that goes with it.

How do I get one health indicator per PLC?

Give each PLC one heartbeat tag and one screen indicator bound to it: the PLC steps its tag on a 1 s clock, and the indicator that stops stepping belongs to the connection that went down.

Many panel packages include a handshake function for exactly this: you designate a tag, the panel watches it, and the setup fields live in your software's help. Where your package has none, bind the indicator straight to the heartbeat word.

On the PLC side, step a counter word on a fixed clock instead of a single toggle bit. A poll can land on the same phase of a toggle twice and read an unchanged state for as long as the two periods stay locked; a counter that gains at least 2 steps between polls reads a new number at every poll, whatever the phase. With a poll interval of 2 s and a counter stepping every 1 s, each poll window gains 2 s / 1 s = 2 steps, which clears the bar. Keep the step interval at half the poll interval or faster.

Then wire the display: one indicator per PLC on the overview screen, bound to that PLC's status tag, plus a numeric readout of the counter if you want the raw value visible. The same status bit can drive an automatic jump to a fault screen; event-triggered screen changes on an HMI when a PLC alarm bit turns on shows the trigger setup. How you split polling across several PLCs is its own decision, covered in one HMI reading two PLCs: poll both or link them.

How do I reset a failed PLC's tags without fighting the fault?

Do the resetting in the PLC, on its first scan after power-up: the PLC owns its data, the comm-fail-tag trigger left the display unchanged, and a first-scan init needs no operator and no screen logic.

The split of work:

• While the PLC is down: bind the visibility or the color of that PLC's data objects to its status tag, so the operator sees greyed or hidden values and reads them as not live.
• When it comes back: the PLC initializes its own working values on the first scan. The panel reads fresh numbers with no operator action, and the indicator clears on its own.
• On the screen: nothing. Writes from objects like a text entry box into internal tags are blocked while the fault stands, so any recovery built on screen entry or a comm-fail trigger sits behind a blocked path.

Check it: cycle one PLC off and on. After it returns, its values read as initialized, its objects unmask, and the indicator clears without a touch on the panel.

What does a worked example look like with 3 PLCs on one panel?

Take 3 PLCs on one Ethernet panel, names NORTH, SOUTH and FILLER, a heartbeat counter in each stepping every 1 s, and a panel poll interval of 2 s: 2 s divided by 1 s gives at least 2 counter steps between polls, so every poll sees a change.

Example addresses and tags, all illustrative:

At 10:20 the north compressor's PLC supply drops. Hold it off 60 s, long enough for the panel to time the connection out, retry, and settle. What you should see:

• The bar across the screen carries NORTH, and only that name.
• The NORTH indicator drops to its fault state; SOUTH and FILLER keep stepping, 60 steps on each counter over the 60 s hold, 2 steps per poll window.
• The north compressor's pressure and rate objects show masked or greyed, while the other two columns keep updating live values.

Power the PLC back. Its first scan reinitializes its working values, the NORTH indicator clears with no operator action, and the masked objects come back reading initialized numbers. The result: identification to one device inside one timeout period, and a recovery with zero screen actions.

How do you prove the setup works before you trust it?

Power the PLCs off one at a time and leave each one off for a full 60 s: connection timeouts are set in seconds, so 60 s is long enough for the panel to declare the fault, retry, and settle the bar and indicators before you judge them.

Taking a PLC down stops whatever it controls, so schedule the outages with production and follow your plant's lockout procedure before you touch a power switch. Then run this sequence:

1. All 3 PLCs running: three healthy indicators, no name on the bar.
2. PLC 1 off, 60 s: its name on the bar, its indicator faulted, its objects masked. PLCs 2 and 3 keep updating.
3. PLC 1 back: indicator clears, values read initialized, nothing touched on the panel.
4. Repeat steps 2 and 3 for PLCs 2 and 3. Three single-outage runs in total.
5. Two PLCs off together: see what your panel shows, because the bar names the device it is reporting and may not carry two names. The indicators are the reference either way.
6. One network-side run: unplug one PLC's cable for 60 s. A power failure and a network failure reach the panel the same way, as responses that stopped, so note how your panel words each and write it on the board.

That is 3 + 1 + 1 = 5 outage runs, and after them the setup has named every failure the line can produce.

Which mistakes make a multi-PLC setup lie to you?

Four setup mistakes produce wrong or missing identification: two device entries sharing one IP address, testing with the cable only and never with power, recovery logic that depends on screen writes, and live data trusted while its status tag shows the PLC down.

• Two entries, one IP address. Both connections fail together, so the names stop meaning anything. One entry and one IP address per PLC, 3 entries for 3 PLCs.
• Cable-only testing. A pulled cable and a dead power supply reach the panel as the same silence. Run both tests so you know which words your panel uses for each.
• Recovery on the screen. Internal-tag writes are blocked while a communications failure stands. Keep every reset in the PLCs, on first scan.
• Trusting frozen values. A column that stopped stepping is showing history. Gate every live object on its PLC's status tag before someone dials a setpoint into a dead number.
• Names like 'PLC 2'. Name the equipment. The bar and the indicators are read by the operator, and equipment names are the ones that read at a glance.

Recommendation: make two additions standard on every multi-PLC panel: a distinct device name per connection in the panel's communication setup, and one heartbeat tag per PLC with its own indicator on the overview screen. With one or two PLCs the device name alone is enough; past four or five connections, move the indicators to their own overview screen so the whole set reads at a glance.

Questions