Before any Modbus or serial protocol can work, the RS-485 wires underneath it have to be sound, and when a multidrop bus refuses to communicate the fault is very often physical: reversed polarity, missing or doubled termination, a broken idle bias, or a node dragging the bus down. Those are things you find with a multimeter and, when you need it, a scope, not with protocol software. This guide is the hands-on physical-layer procedure the protocol pages assume you have already passed: prove A and B polarity, check the idle bias voltage, confirm termination is right, find a misbehaving node, and confirm the bus is daisy-chained rather than star-wired.
Test a serial RS-485 SCADA link in one line: Testing an RS-485 SCADA link is a physical-layer procedure done with a multimeter and sometimes a scope. Confirm A and B polarity is consistent at every node, measure the idle-state bias voltage between the pair to prove the bias resistors are pulling the bus to a defined level, verify a 120-ohm termination resistor at each of the two ends only, check the bus is a daisy chain and not star-wired, and isolate any single node that collapses the bias or causes poll collisions. Passing these proves the wiring before you blame the protocol.
The symptom is usually stark: no communication at all on a multidrop bus, or communication that works with some nodes and fails with others, or a bus that runs for a while and then garbles under load. Because RS-485 carries the signal as a voltage difference between two wires, usually labelled A and B or D- and D+, most of these symptoms trace to something wrong with that differential pair, its reference levels, or its terminations rather than to the protocol riding on top. That is why the right first move on a dead serial link is a meter on the wires, not a packet capture.
The common physical faults are a short list. Reversed A and B polarity at a node inverts the signal that node sees, so it either cannot decode anything or corrupts the bus when it transmits. Missing termination lets the fast edges reflect off the unterminated end and smear the signal, while termination at the wrong places, or more than the two ends, over-loads the drivers. A missing or broken bias network leaves the bus floating at an undefined level when no device is transmitting, so the first character of every message can be misread. And a single faulty node can hold the bus in a bad state, transmit when it should not, or answer at the wrong address and collide with others.
Two structural mistakes underlie many of these. RS-485 is designed as a linear daisy chain, one cable running node to node to node, with the two physical ends terminated, and wiring it as a star with several spurs off a central point creates reflection points that no single termination scheme can tame. The bus is also half-duplex on a two-wire link, meaning every device shares one pair and takes turns, so only one may transmit at a time and any device that fails to release the bus, or two devices set to the same address, will collide. Keeping the daisy-chain and half-duplex nature in mind explains why the tests below focus on polarity, bias, and termination at specific points.
Start with polarity and continuity, powered down where practical. Confirm that A connects to A and B connects to B at every node along the chain, because a single reversed pair at one device is enough to break that node and can disturb the whole bus when it transmits. With the bus wiring traced, power the network up but hold the master idle, and put a DC multimeter across the pair. A properly biased RS-485 bus at idle sits at a small, steady differential voltage, a few hundred millivolts to a volt or two, held there by the bias resistors so the receivers see a defined mark state. A reading of essentially zero volts differential at idle means the bias is missing or broken, which is a classic cause of the first byte of every message being lost.
Next confirm termination. There should be one termination resistor, nominally 120 ohms to match the cable, at each of the two physical ends of the daisy chain and nowhere else. With power off you can measure resistance across the pair: two 120-ohm terminators in parallel read around 60 ohms, a single terminator reads near 120, and a reading far from these tells you terminators are missing or that extra ones have been added at intermediate nodes. Too few terminators leave reflections; too many drag the differential voltage down so far that receivers cannot see a clean signal, which also shows up as a weak idle bias in the previous test. Fix the count so exactly the two ends are terminated.
When the DC checks pass but data is still garbled under traffic, reach for a scope. Probing across the pair while the bus is polling shows the actual differential waveform: clean, square transitions between two well-separated levels mean the physical layer is healthy, while rounded edges, ringing, or transitions that barely separate point at reflection from bad termination, excessive stub length, or too long a cable for the baud rate. The scope is also how you catch a node transmitting out of turn or two devices driving at once, which appears as garbled overlapping edges during a window when only one device should be talking. That collision pattern points you at a duplicate address or a device that is not releasing the bus.
When the bus is physically sound overall but one part of the network misbehaves, isolate by division. Because it is a daisy chain, you can disconnect the bus at a midpoint and test each half independently, or unplug nodes one at a time, to find the device that collapses the bias, garbles traffic, or collides. A single node with a failed transceiver can load the bus enough to pull the idle voltage down or to jam transmissions, and it will often only reveal itself when it is the one connected. Duplicate addresses are found the same way: if two nodes answer the same poll and collide, temporarily removing one and seeing the other respond cleanly confirms the clash, after which you readdress one of them.
Keep the multidrop limits in view while isolating, because they explain intermittent, load-dependent failures. Every node and every terminator loads the drivers, cable length and stub length limit the baud rate you can run cleanly, and a bus that is marginally too long, too heavily loaded, or star-wired may pass a bench test with two devices and fail only once the full population is on and polling fast. The RS-485 concept page covers these electrical limits; the practical field lesson is that a link which works at low speed or with few nodes but fails at full speed or full population is telling you the physical margin, not the protocol, has run out.
All of this sits underneath SCADA, which is exactly why it matters. A SCADA master, whether a local RTU or a cloud platform such as Merobix reaching a site over a gateway, can only poll what the RS-485 wiring lets it reach, so a polarity or termination fault presents up in the system as timeouts or comm-fail alarms that look like a protocol or device problem but are not. When a whole serial segment of tags goes bad together while the rest of a site is healthy, suspecting the shared physical bus first, and running this meter-and-scope procedure, resolves the root cause faster than re-checking every device's protocol settings. Proving the physical layer good is the foundation the entire monitored data path stands on.
With the bus powered and idle, put a DC multimeter across the pair. A correctly wired and biased RS-485 bus shows a small steady differential voltage of a few hundred millivolts to a volt or two, and the sign of that reading tells you which wire is which relative to your meter leads. Confirm A connects to A and B to B at every node, since a single reversed pair breaks that node and can disturb the whole bus when it transmits.
Exactly two, one nominally 120-ohm resistor at each of the two physical ends of the daisy chain and none at intermediate nodes. With power off you can verify this by measuring resistance across the pair: two terminators in parallel read around 60 ohms and a single one reads near 120. Too few leaves signal reflections that garble data, while extra terminators drag the differential voltage down so receivers cannot see a clean signal.
That load-dependent pattern usually means the physical margin has run out rather than a protocol fault. Every node and terminator loads the drivers, and cable length, stub length, and star wiring all reduce the clean baud rate you can run, so a bus that passes with two devices can fail once the full population is polling fast. Confirm it is a daisy chain with only the two ends terminated, shorten stubs, and if needed lower the baud rate or reduce loading.
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.