Duplicate Modbus Slave IDs: Find Bus Collisions

Your bus works fine most of the time — then readings jump, CRC errors appear out of nowhere, and one device only misbehaves when another is powered on. Before you blame the cable, check the simplest cause with the weirdest symptoms: two devices on the same bus configured with the same slave ID. Both answer the same request, their replies collide on the wire, and you get garbage that looks like everything except an addressing mistake.

Symptoms of a slave ID collision

• Intermittent CRC errors — sometimes the read is clean, sometimes it fails, with no pattern. Two overlapping replies corrupt each other’s frames.
• Readings that jump between two values — whichever device’s reply wins the collision this time decides what you see.
• Works with one device disconnected. The single most diagnostic symptom: unplug device B and device A is suddenly rock solid.
• Wrong device responds. You poll ID 5 expecting the energy meter and get the temperature sensor’s registers — because both are ID 5.

Duplicate responses causing bus collisions are a documented classic in Modbus troubleshooting write-ups (e.g. IoTStudioz’s 2025 field notes list duplicate IDs among the top causes of “mystery” CRC errors). The insidious part is that a single-device test always passes — the collision only exists when both twins are on the bus.

How to find the duplicate

Method 1 — disconnect one by one (small buses). Power down everything. Bring devices up one at a time, polling each from QModMaster as you go. The moment the errors start, the last device you added shares its ID with one already on the bus.

Method 2 — binary search (large buses). Split the bus in half (disconnect the middle). If the errors persist, the duplicate pair is in the connected half; if they stop, it’s in the disconnected half. Repeat until two devices remain.

Method 3 — watch the bus monitor. QModMaster’s Bus Monitor shows raw traffic. Poll the suspect ID once: if you see two replies (or one reply with doubled/corrupted bytes), you’ve caught the twins red-handed.

Once found, change one device’s address — via DIP switches, its configuration menu, or vendor software — then power-cycle it (many devices only read their address at boot). Re-poll from QModMaster to confirm each ID now answers exactly once.

Prevent it: plan the ID table before power-up

• Write down every device and its slave ID before wiring — a simple table on paper beats debugging later.
• Don’t trust factory defaults: many devices ship as ID 1. Two “fresh out of the box” devices on one bus are already a collision.
• Label each device with its ID (tape + marker is fine).
• Reserve a block per device type (e.g. meters 1–9, inverters 11–19) so future additions don’t collide.
• After any change, do a full-bus poll from QModMaster and confirm every ID responds exactly once.