A multidrop RS-485 bus shares one pair of wires among many devices, and that sharing works only because exactly one device transmits at a time. When two devices talk at once - because they share an address, because an unsolicited message lands mid-poll, or because polls overlap - their signals collide on the wire and garble each other. The result is intermittent CRC errors and dropouts that look maddeningly random. This guide explains how a poll collision happens and how to distinguish bus contention from a single dead device.
Multidrop poll collision in one line: A poll collision on a multidrop RS-485 bus happens when two devices transmit simultaneously on the shared pair, so their signals overlap and corrupt each other. The usual causes are two devices configured with the same address answering the same poll, an unsolicited or delayed reply arriving while another device is transmitting, or overlapping polls from a mis-timed master. The symptom is intermittent CRC or framing errors and seemingly random dropouts, rather than one device consistently silent.
RS-485 multidrop uses a single differential pair that every device on the segment shares, so the medium is half-duplex: at any instant, only one transmitter may be driving the line while all others listen. The protocol enforces this with a strict turn-taking discipline - the master addresses one device, that device alone replies, and everyone else stays in a high-impedance receive state. There is no built-in arbitration to referee two devices that ignore the turn order, unlike networks designed for contention. The whole scheme rests on the assumption that exactly one device transmits at a time, and it has no graceful recovery when that assumption is violated.
When two devices drive the line at once, their signals superimpose electrically. The receiver sees a waveform that is neither device's message but a corrupted blend, and the frame fails its checksum or framing check. Neither transmitter is malfunctioning in isolation; each is doing exactly what it was told. The fault is emergent - it exists only because two of them acted simultaneously on a medium that permits only one. That is what makes a collision fundamentally different from a device failure and why it produces a scattershot symptom instead of a clean, repeatable one.
The most common cause is a duplicate address. If two devices on the bus share the same unit ID or slave address - a commissioning oversight, a device swapped in without re-addressing, or a default address left unchanged - then every poll to that address is answered by both, and their replies collide. This is insidious because each device individually is fine and might even answer correctly when the other happens to be quiet, so the errors come and go depending on timing. A second cause is unsolicited traffic: a device or protocol that sends a report by exception or a delayed response can begin transmitting while the master is mid-transaction with another device, stepping on the ongoing reply.
Timing at the edges of a transaction is a third contributor. RS-485 transceivers need a moment to turn the line around between receiving and transmitting, and if a device is slow to release the bus, or the master starts the next poll before the previous reply has fully drained, the tail of one message overlaps the head of the next. A poll schedule that is too aggressive for the devices' turnaround time, or a master that does not wait long enough for a reply before moving on, manufactures collisions even with unique addresses. In every case the common thread is overlap in time on a medium that tolerates none, and the corruption lands on whichever transaction happened to be in progress.
The key diagnostic distinction is consistency. A single dead device fails cleanly and repeatably: it never answers, so its poll times out every time while every other device on the same bus keeps responding perfectly. A collision fails inconsistently: the errors are intermittent, they can move between devices, and the affected device answers sometimes and garbles other times. If you see CRC or framing errors scattered across the bus, or a device that responds intermittently while its neighbors are also occasionally disrupted, contention is far more likely than a hardware failure. A telling test is to reduce the bus to one device at a time - if each works alone but they fail together, the medium is being shared badly, not broken.
A cloud SCADA platform makes this pattern visible through per-device poll statistics gathered over time. When the platform tracks success rate, timeout count, and CRC-error count per device across a segment, a duplicate-address collision shows up as two or more devices with correlated, intermittent failures rather than one device flatlined at zero. That signature - shared, timing-dependent errors versus a single consistent silence - is exactly what separates a collision from a dead node, and having it recorded rather than guessed at points the technician toward re-addressing, slowing the poll schedule, or hunting an unsolicited talker instead of swapping a healthy device. On a platform such as Merobix supervising many remote serial buses, that statistical view is what turns random-looking dropouts into a diagnosable contention problem. This failure mode is not covered by the RS-485, Modbus unit-ID, or poll-schedule pages, which describe the mechanisms rather than the collision itself.
Random, intermittent dropouts across a shared RS-485 bus are a classic sign of a poll collision - two devices transmitting at once and garbling each other, most often because two share the same address, or because an unsolicited reply or overlapping poll steps on an in-progress transaction. The randomness comes from the errors depending on timing, so a device answers sometimes and fails other times. A single dead device, by contrast, fails consistently every poll.
Consistency is the giveaway. A dead device times out every single poll while all its neighbors respond perfectly; a collision produces intermittent errors that can move between devices and correlate across more than one node. Per-device CRC and timeout statistics make this clear, and reducing the bus to one device at a time is a strong test - if each works alone but they fail together, you have contention on a shared medium, not a broken device.
Yes - duplicate addresses are the most common cause of multidrop collisions. When two devices share a unit ID or slave address, both answer every poll to that address and their replies collide on the wire, producing CRC or framing errors. Because each device is individually healthy and only collides when both happen to transmit together, the failures are intermittent and hard to pin down until you check for the duplicate and re-address one of them.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.