Technical Guides / Maintenance

Maintenance

Finding a duplicate Modbus address without pulling the loop apart

A duplicated address does not stop the bus. It produces one garbled reply and a working system, which is why it survives commissioning. The symptom is intermittent, so the diagnosis has to be systematic.

A duplicate address is the most common RS-485 fault after wiring, and it is the one that survives commissioning. Two slaves answering to the same unit ID do not bring the bus down. They collide, one reply is lost, the master retries, the retry lands when the other device is quiet, and the poll succeeds. The system looks healthy and produces a scatter of communication errors that everyone learns to ignore until something actually depends on those readings.

What actually happens on the wire

RS-485 is a two-wire shared bus with no arbitration. Every slave hears every request. A slave whose unit ID matches transmits; every other slave stays silent. Nothing in the protocol stops a second device from matching the same number and transmitting at the same time.

Two drivers on one pair at once produce a bit pattern that is neither reply. If one device uses a bias resistor and the other does not, or the two are at different distances, the stronger signal usually wins. That is why the symptom is not “no response” but “the wrong value, occasionally”.

The symptoms, ranked by how much they tell you

Errors that appear after adding one device. The single most reliable indicator. A bus that was clean for two years and started logging CRC errors the day a new transmitter went in has a new address conflict.

One channel that reads plausibly but wrongly. A temperature from the wrong device is still a temperature. Operators believe it.

Errors clustered in time. Collisions happen when both devices are polled in the same cycle, so the faults repeat in a pattern that follows the polling sequence rather than the process.

The whole bus failing at one address. If the master aborts a transaction whenever it reaches unit 12, and unit 12 is fine on a bench, suspect a second unit 12.

A device that works alone and fails on the bus. It did not stop working. It was never being heard.

Five checks, in this order

1. Does the failure follow an address or a device? Poll every address in the range with a single known-good device on the bus. Then swap the suspect unit for a different device with the same address. If the fault follows the address, the problem is on the master side or in the register map. If it follows the device, the failure is that unit.

2. Listen while polling only the suspect ID. Connect a serial analyser or a laptop with a second interface, set to listen only, and poll that one address. One request should produce one reply, with a gap after it. Two replies, or a reply that is visibly two frames overlapping, is the duplicate confirmed. This is the only test that proves the diagnosis rather than suggesting it.

3. Check the four settings that look identical to a duplicate. Before dismantling anything, confirm that all of these match on every node:

SettingCommon mismatch
Baud rateOne device left at 9600 while the master runs 19200
Parity and stop bits8N1 sent to a device set to 8E1
A and B polaritySwapped at one device, works until another is added
Reply delayA slow node’s reply arriving after the master has timed out, then being read as the next reply

Each of these produces intermittent errors and each is faster to check than opening an enclosure.

4. Check termination and bias. Exactly two terminations on the bus, one at each physical end, and none in the middle. A third 120 ohm resistor loads the pair and reduces the differential swing. Bias resistors belong in one place only, usually the master. A bus with no bias and no termination can produce reflections that the master reports as CRC errors on random addresses, which looks exactly like a duplicate.

5. Walk the addresses. Physically. Read the address off each device’s display or label and write it down against its tag number. In most plants the conflict is discovered in the last row of that list, on a transmitter that was configured on a bench and never changed.

Preventing it

The reason duplicate addresses appear is that the address is set on the device, in a menu, by whoever installed it, with no central record.

Keep a register map as a controlled document. Tag number, unit ID, baud, parity, register offset and firmware version for every node. Update it at commissioning, not afterwards.

Assign address blocks by area. Pump room 1 to 10, tank farm 11 to 20. A conflict then requires two people to make the same mistake in different buildings.

Never use address 0. It is the broadcast address, and every slave on the bus will attempt to answer or act on it. Addresses 248 to 255 are reserved by the specification. The usable range is 1 to 247.

Set the address before mounting, and record it after. A transmitter installed at height with an address set by default is a service call waiting to happen, because changing it later requires the same access as replacing it.

When the wrong value is worse than no value

A duplicate address that makes a channel read zero is noticed, because zero trips an alarm in most systems and someone investigates. A duplicate that makes a channel read a plausible number from another device is not noticed, and it is the case that reaches an incident report.

If a bus is producing unexplained intermittent errors, treat the readings from that segment as unverified until the cause is found. The instrument is not necessarily wrong. It is unproven, and those are different things.

Protocol settings, register maps and supported address ranges vary by module and firmware version. Confirm against the protocol document supplied with the specific product before commissioning.