Thirty-Six Tags at Zero Degrees: The Modbus Address Clash That Fooled a GE PLC

A troubleshooting review of duplicate slave addresses, based on the instrumentationtools.com article “18 Temperature Sensors Fault Leads to Plant Shutdown”.

The Incident, Step by Step

The instrumentationtools.com report reads like a detective story. Eighteen temperature tags on a PLC began flickering to zero. The pattern repeated for two days. Then the values stayed at zero. The instrumentation engineer pulled a permit and inspected the area one temperature multiplexer. A red fault LED confirmed trouble, and a power reboot did not clear it.

First, he swapped in a pre-configured spare module. Second, disaster expanded. Eighteen more tags in another area also dropped to zero. The spare mux had been bench-tested. Another engineer had set its Modbus address to 2 during that work. The healthy area two mux also carried address 2. Therefore, two slaves answered the same polls on one serial bus. The GE PLC saw collisions and reported garbage, which the display rendered as zero degrees.

Why One Address, Two Devices, Breaks Everything

Modbus RTU is a master-and-reply protocol. The master sends a poll frame containing one slave address. Exactly one device should answer. However, when two devices share that address, both transmit. Their frames collide on the wire. The master discards the corrupted reply, retries, and eventually marks the register invalid. Meanwhile, the untouched second device keeps polling normally, and the operator watches numbers vanish for no visible reason.

Moreover, the failure looks random. Area one data arrived as area two values, because only the surviving responder answered. That mismatch explains the eerie moment in the report. When the engineer powered off the area two mux, area one tags reappeared with wrong values. The lesson is blunt. On a shared serial bus, address integrity equals data integrity. A duplicate address is not a cosmetic error. It silently invalidates healthy field equipment.

The Human Root Cause Behind a Hardware Failure

Nothing failed in this plant. Configuration did. The spare mux was installed hot from a bench where others had worked on it. No one verified its address before energizing. Therefore, treat every spare as untrusted until proven. I have seen the same pattern with Schneider drives set to conflicting addresses. Duplicate Modbus TCP ports across gateways cause equal chaos.

First, blame the process, never the person. The missing step was a verification gate, not effort. Second, make addresses visible. A sticker on the module costs nothing. Third, keep a live address register in the maintenance database. When every addressable device appears in one table, duplicates surface during planning instead of during production.

A Pre-Install Verification Procedure

1. Query the address register before touching any spare device. Confirm the planned address is reserved for your bay.
2. Configure on the bench: address, baud rate, parity, slave ID.
3. Label physically. Write the Modbus address on the module and inside the enclosure door.
4. Isolate before energizing. Disconnect or disable other segments while the new device answers its first poll.
5. Verify from the PLC side. Force a known input, watch the correct tag move, and confirm no neighbor tags flicker.
6. Close the record. Update the address register, loop drawing, and permit with date and initials.

Design Choices That Reduce the Risk

Configuration mistakes deserve architectural defense. First, segment your networks. More nodes on one RTU line means wider blast radius for one bad address. Second, prefer devices with front-panel address displays or push-button setup. Blind DIP switches invite errors that no one checks.

Moreover, poll health must reach the operator. Configure the PLC to alarm on communication failure per slave, not per bus. A zero-value alarm also matters badly here. In this incident, the “0 degrees” reading masked a data fault as a process value. Therefore, scale your range so under-range or quality-bad states are unmistakable. Finally, store spare parts with their intended address written on the box. A pre-addressed spare is a safe spare.

Conclusion & Action Advice

Duplicate addresses are among the cheapest incidents to prevent and the hardest to diagnose live. Verify the address register before installing any spare, label every device, and isolate segments at first poll. Give your operators communication alarms that cannot hide as zero values. Plants that run these three habits keep Modbus buses quiet. A healthy spare then stays what it is.

Author: Qian Zhiyuan is an industrial automation engineer with over 10 years of experience in PLC, DCS, and control systems.