Keep an HMI usable when one of two PLCs goes offline

Can I suppress the comm error and keep the live PLC on screen?

Yes, but the working change is the per-controller communication-error handling the panel documentation covers as help topic CM525, applied so a single failed connection among your two controllers stops blocking the screen; hiding the alarm message alone leaves the update behavior unchanged.

The alarm and the connection are two different things. The alarm tells the operator a path died. The connection is what the runtime polls, screen by screen, tag by tag. Suppressing the alarm edits what the operator sees; the dead connection still sits in the update path and still stalls it. What you want is both halves handled separately per controller: the failed connection marked offline, the healthy connection served without waiting on the dead one. Each PLC in a two-controller project is its own connection with its own address and its own tags, the same structure as pointing one HMI panel at several PLCs with per-device tags.

Why does one dead PLC freeze the whole panel?

Because the project lets a failed controller connection sit inside the screen-update path: the poll to the dead PLC waits out its timeout, screens that reference it stop updating, and on a project built this way the whole interface stops taking touches.

Read the symptoms before changing anything, because five different faults show up as a panel that stopped:

• No touches register and no values move anywhere. One failed connection is blocking the update path for the whole project. The panel hardware is fine; the project's error handling is the suspect.
• Touches work, but values from both PLCs are frozen. The failure is on the shared path: the switch, the panel's Ethernet link, or the panel's network settings. Check the link lights at both ends.
• Values from one PLC update while the other's sit still. The connections already isolate; the failed PLC's own path needs the repair.
• An error banner names one controller. That single connection failed. Write down the exact text; it names the fault for the documentation and for the vendor.
• The panel is dark or restarting. That is power, and you check it first, the same first move as when an HMI screen goes blank and freezes.

How do I prove the second PLC is still talking?

Watch a value that must change at the source, not on the panel: a free-running clock, a cycle counter, or a part counter in the PLC itself, read with the programming software or a second client while the panel shows the same tag.

The clock is the first tag to check, because it changes every second on a healthy controller. Then check each path on its own: the link lights at the switch and at each PLC, power on both controllers, and the failed PLC's address and availability, all without touching the healthy PLC's settings. Watch whether the panel recovers on its own when the failed PLC comes back. Note the timeout behavior too: a project that keeps polling controllers which are gone spends its scan waiting on them, the problem behind an HMI polling PLCs that are not installed, and it slows the live side even when nothing has failed.

Where is the setting that stops one comm error freezing the panel?

In the panel's own help system, under help topic CM525, the communication-error topic: it walks the settings that decide what the runtime does when a controller connection fails, and you apply it per controller, with a copy of the project saved first.

1. Save the project under a new name. That file is your way back.
2. Write down the exact error text the panel shows, plus each controller's address and connection settings.
3. Open help topic CM525 and follow it for your installed software version; the control names and their wording live on that page.
4. Apply the handling to each controller connection: a failed poll marks that controller offline and stops interrupting screens that use the other one.
5. Keep one alarm per controller routed to a visible indication, so the fault stays on record for the operator.
6. Download to the panel under controlled conditions, following the panel's documented transfer procedure, with the line in a state where a frozen screen for a minute is safe.

How do I show one PLC as offline without lying to the operator?

Drive the indication from the connection status and blank the dead PLC's numbers: an offline banner or dashes where its values stood, so nothing on screen reads as current data from a controller that is down.

Numbers that stopped changing but stayed lit get read as live by whoever glances at them, and a frozen temperature or a frozen level is how an operator makes a wrong call with real consequences. Blank the values, name the controller, and keep every control that writes to the dead PLC visibly unavailable so nobody queues a start against it. Values and controls from the healthy PLC stay in service; that is the whole point of the change.

Example: how do I run the dropout test with real numbers?

Take one PLC offline for 60 seconds and count: a case counter that ticks every 2 seconds must climb by 30 counts in that window, so a reading that moves from 4,187 to 4,217 proves the live connection is refreshing while the other controller is down.

A packaging line runs one panel against two controllers. PLC 1 counts finished cases, one count every 2 seconds while the line runs. PLC 2 carries the dryer temperature and its alarm list. Both show on one screen.

With both controllers online, the case counter reads 4,187 and climbing. Put PLC 2 in STOP with its mode selector; its mode lamp shows the change within 1 to 2 seconds, which is how you know the controller really went down and the panel now faces a dead connection. Hold that state for 60 seconds. The arithmetic: 60 seconds at one count per 2 seconds is 60 / 2 = 30 counts, so the panel should read 4,187 + 30 = 4,217. Change screens and press buttons while you wait; they should answer. The dryer temperature shows dashes with an offline mark, and the banner names PLC 2 only.

Return PLC 2 to RUN; its values resume and the offline mark clears. Then swap roles: hold PLC 1 in STOP and confirm the dryer temperature keeps moving while the case count shows dashes. Two tests, 60 seconds each, one per connection, is the minimum acceptance bar.

If the case counter sits at 4,187 while PLC 1 runs, the isolation change did not take: restore the backup and re-read the topic for your software version before the second attempt. Chase the stall the same way you would find which layer freezes when a PLC counter stops updating, one layer at a time.

What if the panel still freezes after the change?

Restore the backup project and repair the failed PLC's own path, because the wiring and the controller have to deliver the connection before any project setting can isolate it: power, Ethernet link, addressing, or the controller itself.

If the healthy connection passed its dropout test, leave the revised project in place while you repair the dead PLC, so the operator keeps the working half of the line. If it did not pass, restore the backup and accept the freeze until the repair lands; a panel in its known state is easier to reason about than one in an unknown one. When you call the panel vendor, have the packet ready: software version, project backup, the exact error text, and the time-stamped test results.

Recommendation: apply the per-controller communication-error handling from help topic CM525, keep one visible offline indication per PLC, and accept the project only after the 60-second dropout test passes for each of the two connections. Suppress the error message only where the offline indication already tells the operator the same thing.

If the floor also needs a status board that keeps playing when the controls network is down, shop-floor signage that plays from a memory card runs with no network at all.

Questions