RS-485 on site: what breaks and why

RS-485 is the most common bus by which controllers on site talk to the rest of the system: Modbus RTU over it sits in most bay controllers, meters and frequency inverters. On the bench it always works. On site, a month later, “sometimes it does not respond” begins, and the cause is almost never in the software. Below is the list of what we have found, from most frequent to rare, and how to find it without an oscilloscope.

Topology: a line, not a star

RS-485 is a single line of two wires, with devices attached to it one after another. At both ends of the line sits a termination resistor that absorbs signal reflections. When the line is run as a star — a separate cable from the cabinet to each bay — reflections arise at every branch; at low speed this works, at high speed it does not. The classic sign: everything was fine with three bays, errors started with the sixth.

The second typical mistake is termination. Either there is none at all, or there are three, because everyone who connected a device fitted their own. There must be two terminators, at the physical ends of the line, and nowhere else. Many controllers have a jumper or a DIP switch for termination, and after a device is replaced that jumper is often not where it was.

The third is stubs. A short tail to a device that stands off the line is a small star with the same consequences. If a device cannot be placed on the line, it is better to run the line to it and back than to make a branch.

Ground and the third wire

The two RS-485 wires carry a voltage difference, and the receiver only understands it within a certain range relative to its own ground. If two cabinets at opposite ends of the site have different grounds — and on a site with pumps they almost always do — the signal can leave that range, and the receiver sees rubbish or burns out.

So the third wire, a common signal ground, is needed, and it is often left out because “it works on two”. It works while the potential difference is small. After a thunderstorm, or after someone re-routes the cabinet earth, it stops.

A ground loop is the opposite problem: when the common wire joins two grounds of different potential, current flows through it and induces noise on the signal pair. The cure is galvanic isolation at one end — a separate converter, and it costs less than one site visit.

Length, speed and cable

The longer the line, the lower the usable speed. A baud rate that worked inside the cabinet may no longer work on a line across the whole site. If errors depend on which bay is being polled, it is almost always length plus speed.

The cable must be a shielded twisted pair, and the shield is earthed at one point, not two. Flat telephone cable, two cores from a power cable, anything without a twist — all of it works on the bench. On site next to power lines it turns into an antenna.

Routing alongside power cable is a cause of its own. Even a shielded pair laid in the same tray as the pump supply picks up every start.

Noise from pumps and inverters

A high-pressure pump at a car wash is a motor of several kilowatts, and its start produces a current surge visible on everything nearby. A frequency inverter is worse: it generates high-frequency noise continuously while running, not only along the wires but through the air into any unshielded cable.

The sign of this particular cause: the errors correlate with the equipment. At night, with the pumps idle, there are no errors. On the most powerful programme there are the most. If the Modbus error log shows a correlation with programmes, look at the cable next, not the code.

What helps: shielded cable with the shield earthed correctly, ferrite rings at the controller input, a separate tray, and — if the inverter has an output filter — fitting it. The last one solves the problem most often, but that is an electrician’s job, not a programmer’s.

Modbus RTU timing

Modbus RTU separates messages with silence: between frames there must be a gap of at least 3.5 character times, and a gap longer than 1.5 character times inside a frame means the frame is broken. That is easy on a microcontroller and hard on a computer with an operating system, where the USB converter adds its own delays and the kernel adds its own.

The typical result: on a Raspberry Pi or an industrial PC with a USB-to-RS-485 adapter, some frames “split” in two, and the device replies with an error or stays silent. It looks like random timeouts that do not depend on the equipment and happen even at night.

What to do: check the timeouts in the library, do not poll devices more often than needed, do not mix devices with different response times on one bus without margin, and where possible use a converter with hardware direction control rather than software. One more effect: a device replies too quickly, before the converter has switched to receive, and the start of the reply is lost. That is visible only with a byte-level log.

How to diagnose, and when to move to TCP

A search order that saves time. First the log: when the errors occur, with which device, whether they correlate with time of day and with equipment running. Next, poll each device on its own with the others disconnected: if they answer one at a time but not together, it is topology or termination. Then halve the baud rate: if the errors disappear, it is length, cable or noise. Only then reach for a multimeter to measure the potential difference between cabinet grounds.

Modbus TCP is the same protocol over Ethernet. It removes all the RS-485 problems and adds its own: switches, power, addressing, and one more device on every bay. It is worth moving to it when there are many bays and they are far apart, when the site already has a network, or when RS-485 cannot be stabilised after two visits. It is not worth it for one controller three metres from the cabinet.

A compromise that often works: short RS-485 segments inside each cabinet and Ethernet between cabinets, through a Modbus RTU/TCP gateway. No long lines, few devices per segment, and each segment can be diagnosed on its own.

Frequently asked

Why did the bus work for a year and then start producing errors

Because something changed, and most often not in the software: a controller was replaced and the terminator ended up in the wrong place, a bay was added as a branch, a new power cable was laid alongside, the earthing changed. Look in the site’s event log for the week it started, not in the code.

Are two wires enough, or is a third needed

Formally the signal travels on two. In practice the third wire, a common ground, is needed almost always, because the potential difference between devices on site rarely stays within limits. If the cable is already laid without a third wire, the shield can take that role, provided it is earthed at one point.

Will moving to Modbus TCP solve the problem

The RS-485 problems, yes, all of them. But it adds others and costs replacing or supplementing equipment on every bay. If the errors are few and localised, fixing the bus is cheaper. If the site is large and the bus cannot be stabilised, TCP pays for itself.