Plenty of working plants still run serial and fieldbus networks, and
they follow rules that trip up technicians used to Ethernet. The
recurring themes are addressing, termination, and the physical
daisy-chain.

Modbus RTU

Modbus RTU is a serial master/slave protocol, usually over RS-485,
common on meters and small drives. For a device that will not respond,
the settings must match exactly on both ends: the same baud rate, data
bits, parity, and stop bits, plus a unique slave address for each
device. RS-485 is a daisy-chain that needs termination resistors at the
two ends of the line — missing or extra termination causes intermittent,
distance-dependent errors that are maddening to chase. Polarity of the
A/B (or D+/D−) lines must also be consistent along the chain.

PROFIBUS DP

PROFIBUS DP, still widespread in older Siemens plants, is likewise a
terminated bus with strict rules. Each device has a unique address. The
bus must be terminated at both physical ends, and — importantly —
PROFIBUS connectors contain switchable terminators that must be ON only
at the ends and OFF in the middle. A single wrong terminator switch, or
a connector knocked loose during other work, can bring down the whole
segment or cause stations to drop intermittently. The diagnostic LEDs on
PROFIBUS connectors and modules, plus the CPU’s diagnostic buffer,
localize a failed or intermittent station.

TERMINATION IS NOT OPTIONAL

On RS-485, PROFIBUS, and DeviceNet, termination is part of making the
signal work, not a nicety. When a fieldbus behaves erratically — fine
sometimes, failing others, worse as you add devices — suspect
termination and cabling before anything electronic.

Why serial settings must match exactly

Serial protocols like Modbus RTU carry no automatic negotiation, so
both ends must be configured identically or they cannot communicate at
all. Baud rate, data bits, parity, and stop bits must match on every
device on the bus, and each device needs a unique address. A single
mismatched parameter — one device set to a different baud rate, or the
wrong parity — produces a device that simply will not answer, with no
helpful error beyond a timeout. When a serial device goes silent after
installation or a settings change, methodically confirm every
communication parameter against the rest of the bus before suspecting
hardware. The fault is far more often a mismatched setting than a failed
device.

Termination: the invisible fault

The most maddening fieldbus faults come from termination, because
their symptoms are intermittent and distance-dependent rather than a
clean failure. Buses like RS-485 and PROFIBUS are transmission lines
that require termination resistors at their two physical ends to prevent
signal reflections. With termination missing, wrong, or duplicated, the
bus may work with few devices and fail as you add more, or work over
short distances and fail over long ones, or fail only intermittently as
conditions shift. Because the bus sometimes works, technicians chase the
devices rather than the termination. The discipline is to treat erratic,
load-dependent, or distance-dependent fieldbus behavior as a
termination-and-cabling problem until proven otherwise. On PROFIBUS
specifically, the connectors contain switchable terminators that must be
on only at the two ends of a segment and off everywhere else — a single
wrong switch, easily flipped during other work, can disrupt the whole
segment.

Addressing and the daisy-chain

Fieldbuses are typically wired as a daisy-chain — device to device to
device — rather than the star of Ethernet, and this shapes their faults.
A break anywhere in the chain can cut off every device beyond that
point, so a group of devices failing together often points at a single
break or loose connector upstream of them all. Each device needs a
unique address on the bus; a duplicated address causes conflicts that
can appear as intermittent faults on the affected devices. When
commissioning or after adding a device, address conflicts and a
disturbed daisy-chain connection are the usual suspects. Reading which
devices are present and which are missing, in physical order along the
chain, points directly at where the chain is broken.

A case file: the bus that failed as it grew

A Modbus RTU network over RS-485 worked perfectly with three meters
on it. When the plant added several more meters, extending the run,
communication became unreliable — timeouts and errors that grew worse
the more devices were added and the longer the cable ran. Behavior that
degrades as a bus grows or lengthens is the classic signature of a
termination or cabling problem rather than a device fault. Checking the
bus, the technician finds it was never properly terminated at its ends;
with a short bus and few devices it had worked despite this, but the
longer, more heavily loaded bus could no longer tolerate the reflections
that missing termination allows. Adding the correct termination
resistors at the two physical ends of the line restores reliable
communication for the whole bus. The pattern is worth committing to
memory: a serial or fieldbus network that works small and fails as it
grows, or works short and fails long, is telling you about termination
and cabling, and that is where to look before suspecting any device on
it.

Grounding and isolation on serial buses

Serial buses carry another class of fault rooted in grounding.
Devices spread across a large machine or between machines can sit at
slightly different ground potentials, and that difference can drive
unwanted current along the bus’s reference, corrupting communication or,
in bad cases, damaging ports. This is why many serial installations call
for careful attention to a common signal ground and sometimes for
isolated interfaces that break the ground path while still passing the
signal. When a serial bus suffers errors that correlate with other
electrical events — a large motor starting, welding nearby, or
particular machines running — a grounding or isolation problem is a
strong candidate, because those events shift ground potentials or inject
noise that a poorly grounded or non-isolated bus passes straight into
the communication. The fix lies in grounding and isolation practice
rather than in the devices themselves.

The daisy-chain and the single point that drops
many

The daisy-chain wiring of most fieldbuses creates a distinctive fault
geometry that, once understood, makes many fieldbus faults quick to
localize. Because devices connect in a line, one after another, a break
or bad connection at any point can cut off every device beyond it while
leaving those before it working. So a fieldbus fault where a contiguous
run of devices — all those past a certain point — goes missing together,
while the devices before that point remain healthy, points precisely at
the connection where the working and missing devices meet. Rather than
suspecting each missing device, you look at the single connection
between the last good device and the first missing one, because a break
there explains the entire pattern. This is a powerful shortcut: reading
which devices are present and which are missing in physical order along
the chain localizes the break to a single connection, turning a segment
full of missing devices into one connection to inspect. The controller’s
view of which devices it can reach, mapped against the known physical
order of the daisy-chain, is what makes this localization possible.

A case file: the terminator switch

A PROFIBUS segment that has worked for years suddenly becomes
unreliable after unrelated work was done in a panel it passes through,
with stations dropping intermittently. The timing — trouble beginning
right after physical work near the bus — strongly suggests something was
disturbed during that work rather than a coincidental device failure. On
PROFIBUS, the connectors contain switchable terminators that must be on
only at the two ends of the segment, and the technician finds that a
connector in the middle of the segment, disturbed during the recent
work, has had its terminator switch inadvertently flipped on. The extra
termination in the middle of the segment disrupts the signal, causing
the intermittent station dropouts. Returning the switch to off restores
reliable communication. The case captures a PROFIBUS-specific trap: the
terminator switches in the connectors are easily flipped during other
work, and a wrongly set terminator — on in the middle, or off at an end
— disrupts the whole segment, so a PROFIBUS problem that begins right
after physical work near the bus should prompt a check of every
connector’s terminator switch, since a single wrong switch explains
segment-wide intermittent faults that would otherwise be baffling.

A case file: the address conflict on the bus

After a device is added to a Modbus RTU network, that device and an
existing one both begin communicating unreliably, with intermittent
responses and timeouts affecting the two of them while the rest of the
bus is fine. Two devices misbehaving together, specifically after a new
device was added, points at a conflict introduced by the addition, and
on a bus where each device must have a unique address, the classic such
conflict is a duplicate address. The newly added device was configured
with an address already in use by an existing device, so the two share
an identity on the bus and interfere with each other’s communication,
producing the intermittent, mutual unreliability affecting exactly those
two. The other devices, with unique addresses, are unaffected.
Reconfiguring the new device to a genuinely unique address resolves the
conflict, and both affected devices return to reliable communication.
The case captures a fault pattern specific to addressed buses: when
adding a device causes that device and one existing device to become
mutually unreliable while the rest of the bus is fine, an address
conflict between those two is the likely cause, because a duplicate
address makes two devices contend for one identity and disrupts both.
The pattern — two devices, mutual disruption, onset after an addition —
is the signature, and it points at checking the new device’s address for
a conflict with an existing one rather than at any hardware fault, since
the devices are healthy and merely sharing an identity they must not
share. This is why unique addressing is fundamental on such buses and
why address conflicts are among the first things to suspect after any
device is added.

Part VI — Machine Faults and Systematic
Diagnosis

Leave a Reply

Your email address will not be published. Required fields are marked *