# RS-485: why the shop floor uses a bus, not a star

> Industrial devices share one line for a reason that has nothing to do with saving cable. Knowing that reason explains half the problems on a site.

Source: https://naasson.com/en/blog/rs485-why-the-shop-floor-uses-a-bus/
Published: 2026-05-29
Language: en
Direction: Industry by Naasson (https://naasson.com/en/industry/)
Publisher: Naasson — https://naasson.com

---
A network engineer walking onto a shop floor for the first time is usually surprised by the topology. Instead of the familiar star with a switch in the middle, there is one shared line with dozens of devices daisy-chained along it.

This is not a legacy of poverty. The topology has reasons, and those reasons determine what breaks on site.

## Why a bus

Distance. A shared line works over distances an ordinary LAN cannot reach, with no active equipment along the way.

Noise immunity. Differential signalling over a twisted pair tolerates the electrical noise of a workshop: welding, drives, motor starts. This is the main reason. In a room where a variable-frequency drive is running nearby, a lot of things simply do not work.

Simple devices. A device needs no network stack. That makes it cheap and very reliable.

## What this means for operations

A shared line means a shared fate. One faulty device can corrupt communication for every other device on the same line.

The symptom looks random: some polls succeed, some fail, different devices answer differently at different times. Finding the cause means disconnecting devices one by one.

Hence a practical requirement for the site description: you must know which devices sit on the same line. Without that, the failure pattern makes no sense. The devices are logically independent and physically not.

## Termination, present and missing

The ends of the line need termination. A missing terminator, or one in the wrong place, causes signal reflections and communication errors, again intermittent and again easy to mistake for anything else.

This is the most common finding when troubleshooting unstable communication on site, and also the most boring. Check it first, before any protocol settings.

## Baud rate as a trade-off

The higher the speed, the shorter the allowed line. The lower the speed, the less often you can poll.

A practical consequence for polling: dense polling occupies the shared bus and interferes with the equipment's normal traffic. Polling must be rate-limited, and the first run on a live production floor must happen in an agreed window.

This rule is usually learned the expensive way. A tool that starts polling everything at maximum rate can disrupt the very line it came to observe.

## Addresses as a resource

Every device on a shared line has its own address, and addresses are assigned by hand, with switches on the housing or in the settings.

Address conflicts are the second most common finding. Two devices with the same address on one line produce answers that look like a single device behaving strangely.

Device discovery helps find such conflicts, but not automatically. They show up as inconsistent answers, and you can only recognise them if you know this can happen.

## Why this belongs in the site description

Because all of the above are properties of the physical layer, and without them diagnosis is impossible.

The line, the devices on it, their addresses, the baud rate, whether termination is fitted, the length. When this is written down, troubleshooting unstable communication starts with checking the description. When it is not, it starts with a site visit and disconnecting devices one by one.