Three Causes of Fieldbus Data Loss: Termination, Address Conflicts and Water in Connectors

"Lost data" on a fieldbus displacement sensor is usually not a measurement problem, but data that did not arrive complete at the master. In site statistics three causes account for the great majority: wrong terminating-resistor configuration, node-address conflicts, and water or damp in connectors. All three can be verified quickly without stripping the equipment. This article gives a troubleshooting order driven by diagnostic counters. For fieldbus wiring basics see A Practical CANopen and EtherCAT Guide; for the principle of termination matching see Terminating Resistors and Bus Length; for general fault criteria see Troubleshooting Magnetostrictive Displacement Sensors.

Look at the diagnostic counters first; do not strip wires first

The largest advantage of fieldbus troubleshooting is that there is objective data to read. The first action is to read communication diagnostics on the master side: error-frame count, Bus-off count, dropped-station records, telegram retry count. Two cases can then be separated:

• The count keeps rising: a physical-layer or matching problem; follow this article;
• The count is not rising but the position value is abnormal: communication is healthy; it is a measurement or configuration problem. Go to Tracking Down Reading Errors or Signal Jump Troubleshooting Flow.

Cause one: terminating resistors — 120 Ω, one at each end

Protocols based on a differential bus, such as CAN / CANopen and Profibus, require one 120 Ω terminating resistor at each physical end of the bus to absorb signal reflections. Three wrong configurations are common on site:

• Only one fitted, or none: reflection distorts the waveform and the bit-error rate rises significantly at high baud rate;
• Three or more fitted: common when every node has a switchable internal terminator and all are switched ON at construction, so equivalent load is too low and drive capability is insufficient;
• The resistor is not at a physical end: fitted on an intermediate node, the end still reflects.

Verification: with the bus powered down, measure resistance between the two differential wires with a multimeter at any point on the bus. With one 120 Ω at each end in parallel, about 60 Ω should be read; about 120 Ω means only one terminator; clearly below 60 Ω means too many terminators. This is the fastest, most definite check.

Cause two: node-address conflicts and inconsistent baud rate

Two nodes set to the same address will, at light severity, leave one node unable to come online and, at heavy severity, make the bus error frequently. Addresses are usually set by DIP switches or software configuration. Easy-to-get-wrong cases are: a batch of sensors all leaving the factory at the same default address, an expansion station reusing an old address, and the bit order of the DIP switches misunderstood (decimal/hexadecimal, high/low bit order).

Baud rate must likewise be consistent network-wide. A CANopen type (such as the 194 CANopen series) supports up to 1 Mbps, but the higher the baud rate, the shorter the allowed bus length — a physical constraint set by the relationship of round-trip propagation time on the bus to bit time. The common practice on a long run is to drop speed deliberately in exchange for stability: better to run through at a lower baud rate than to force 1 Mbps on a long cable. For configuration practice see CANopen Node Address and Baud Rate Configuration in Practice.

Cause three: water and damp in connectors

This is the most frequent hidden cause outdoors, on wash-down and in damp shops. After moisture enters the connector, insulation resistance between the differential pair falls and the signal is weakened or has noise superimposed. The signature is correlation with weather, wash-down and day/night temperature difference: data loss starts after rain or wash-down and recovers after drying.

The check: with power off, open the connector and inspect for water droplets, oxidation marks and a deformed or aged seal; where possible measure insulation between the wires with an insulation tester. Treatment cannot stop at wiping dry: the seal must be replaced and the ingress-protection class confirmed to match the site — IP65/67 for spray, IP68 for immersion, IP69K for high-temperature, high-pressure wash-down. The wrong class will take water again no matter how many times it is wiped. For connector selection and seal maintenance see Selecting Waterproof M12 Connectors and Maintaining Seals; for what the classes mean see IP65/67/68/69K Is Not a Numbers Game.

Criteria and remedies of the three causes

Cause	Typical symptom	Site criterion	Remedy
Wrong terminating resistors	High bit-error rate, worse at high baud rate	About 60 Ω between the differential pair with power off	Leave one 120 Ω at each end; switch the rest off
Address conflict	A node never online, or intermittent	Locate by disconnecting one unit at a time; check DIP switches against the configuration table	Reallocate unique addresses and keep a record
Baud-rate mismatch	The whole segment will not communicate	Check network-wide baud rate against actual bus length	Unify the baud rate; drop speed appropriately on a long cable
Water in the connector	Strongly related to rain/wash-down; recovers after drying	Visual inspection after opening + measure insulation between the wires	Replace the seal; choose the IP class to the site
Improper shielding and earthing	Lost frames when high-power equipment starts or stops	Start/stop the interference source and watch the error-count change	Specify shielding and equipotential bonding; see the earthing topic
Topology violation	Random lost frames; worse as more are connected	Check for star branches / over-long stubs	Change to a specified bus/linear topology

Topology and routing: two items easily treated as "mystical"

A differential bus requires a near-linear topology, and stub length must be limited. On site, to save cable, a star branch is made, or a very long stub is taken from a node; both cause reflection superposition, appearing as "random lost frames, worse as more are connected", and changing the sensor does not improve it at all. Likewise, when fieldbus cable runs in parallel over a long distance with inverter power cable, common-mode interference will raise the bit-error rate significantly. For shield and equipotential treatment see Shield Grounding at One End or Both; for systematic interference troubleshooting see Troubleshooting Fieldbus Interference.

Industrial-Ethernet-class protocols (such as the 197 EtherCAT series, the 199PROFINET series and 198 single-M12 EtherCAT) do not use 120 Ω terminating resistors; the troubleshooting emphasis shifts to link order, cable quality, port error counts and device-name/station configuration, but the "water" and "routing" items apply equally.

Recommended troubleshooting order

1. Read the master's diagnostic counters and confirm it is a communication-layer problem;
2. Measure terminating resistors with power off (the about-60 Ω criterion);
3. Check the address table and baud rate;
4. Open suspect connectors, especially outdoor and low-mounted ones;
5. Check topology and stub length;
6. Observe the correlation of interference-source start/stop with the error count;
7. If all of the above are healthy, then consider isolating nodes one at a time to locate the faulty station.