Symptom
A Modbus device communicates normally for a period and then times out, recovers on its own, and the pattern repeats without an obvious trigger.
The short answer
Modbus Device Intermittently Offline
A Modbus device that drops out intermittently is usually a physical layer problem rather than a configuration problem, because a wrong configuration fails consistently. The most frequent causes are missing or incorrect RS-485 termination, missing bias, no signal common, cable routed near variable frequency drive output conductors, and a response timeout shorter than the device actually needs.
Key points
- Consistent failure means configuration. Intermittent failure means physical layer or timing.
- Terminate both physical ends of an RS-485 segment, and only the ends.
- Bias must exist somewhere on the segment or an idle line floats into noise.
- A missing signal common works until ground potential difference grows.
- Trend the error rate per device; a rising rate predicts a hard failure.
Possible causes and what to check
| Possible cause | What to check |
|---|---|
| Missing or incorrect termination | Confirm 120 ohm termination at both physical ends of the segment only. Measure resistance across the pair with the bus powered down: roughly 60 ohms indicates two terminators present. |
| No bias on the segment | Confirm bias resistors are enabled at one point, usually the master. Without bias the idle line floats and receivers interpret noise as data. |
| Signal common not connected | Verify a common conductor between devices. Many installations omit it and work until ground potential difference grows. |
| Cable near drive output conductors | Trace the routing. Shared conduit or tray with VFD output cable is a leading cause of a bus that fails only when a drive runs. |
| Response timeout too short | Compare the configured timeout against the device actual response time. Some field devices need tens or hundreds of milliseconds. |
| Polling faster than the device can answer | Reduce the poll rate and observe whether the error rate falls. |
| Duplicate slave address | Two devices at the same address answer together and corrupt each other. Disconnect devices one at a time. |
| Marginal or failing transceiver | The device drops out with increasing frequency over weeks. Substitute or move it to another position on the bus. |
| Star topology or long stubs | RS-485 is a bus. Stubs off the trunk cause reflections that get worse at higher baud rates. |
| Loose termination in a junction box | Flex the cable at each termination while monitoring communication errors. |
What intermittent tells you
This is the most useful single deduction available. A wrong slave address, a wrong baud rate, a wrong register, or a wrong parity setting does not work sometimes. It never works. If a device communicates successfully at all, the address, the serial parameters, and the register map are correct.
That leaves the physical layer and timing. It is a much smaller search space than it feels like when you are standing in front of a panel at a remote site.
The physical layer, in the order that finds problems fastest
- 1
Check termination
With the bus powered down, measure resistance across the A and B pair. Roughly 60 ohms means two 120 ohm terminators are present, which is correct. Around 120 ohms means only one, and an open reading means none. Several devices with termination switches left on will read much lower.
- 2
Check bias
Confirm bias is enabled at exactly one point on the segment, normally the master or a dedicated bias network. Without it an idle bus floats between logic states and receivers see noise as start bits.
- 3
Verify the signal common
RS-485 is differential but not immune to common-mode voltage. Devices need a shared reference within the transceiver common-mode range. Confirm the third conductor exists and is landed.
- 4
Inspect the topology
Trace the actual wiring rather than the drawing. Look for a star arrangement, long stubs, or a device T-tapped in the middle of a run with several feet of drop.
- 5
Check routing against noise sources
Look for shared conduit or cable tray with drive output conductors. Check whether failures correlate with a drive running. This correlation alone frequently solves the case.
- 6
Flex the terminations
While monitoring the error count, gently move the cable at each termination and junction. An intermittent connection often reveals itself immediately.
Timing
Modbus RTU frames are delimited by silence, so timing is part of the protocol rather than an implementation detail. Two settings matter more than the rest.
- Response timeout: must exceed the slowest response the device produces under load. A device that normally answers in 20 ms may take 200 ms while performing an internal calculation.
- Inter-frame delay: the master must respect the required silence between transactions. A master that transmits too quickly after a response can collide with a slow device still finishing.
- Retries: set deliberately. Too few and a single noise event marks a device offline; too many and the whole bus stalls waiting on one device.
- Poll rate: reading a device every 100 ms because you can is not a reason to. Match the poll rate to how fast the value actually changes.
Isolating a single bad device
When the whole bus is unreliable and no single device stands out, bisect it. Disconnect half the devices and observe. If the remaining half is stable, the problem is in the disconnected half. Repeat. This takes fifteen minutes and it always converges, which is more than can be said for staring at a wiring diagram.
What good looks like
| Metric | Healthy | Investigate |
|---|---|---|
| Timeout rate per device | Effectively zero | Any sustained rate above about 1% |
| CRC errors | Zero | Any recurring CRC errors indicate noise or reflections |
| Response time | Stable and well under the timeout | Rising average, or occasional long outliers |
| Error correlation with equipment | None | Errors clustering around drive starts |
| Trend over weeks | Flat | Slowly rising error rate predicts a hard failure |
Frequently asked questions
- How do I know if termination is correct?
- Power down the bus and measure resistance across the A and B pair. Approximately 60 ohms indicates two 120 ohm terminators, which is correct for a properly terminated segment. Higher suggests one or none; much lower suggests several devices have termination enabled.
- Do I need the signal common on RS-485?
- Yes, in practice. The differential pair carries the data but every transceiver has a common-mode voltage limit. Without a shared reference, ground potential difference between devices can exceed it, and the bus works until it does not.
- Why does the bus fail only when a pump starts?
- Because the drive output cable is coupling into the communication cable, or the motor current is shifting ground potential between devices. Check routing and separation first, then the signal common, then consider an isolated repeater.
- Should I lower the baud rate?
- It can help as a diagnostic and sometimes as a workaround, because lower rates tolerate reflections and marginal cabling better. Treat a bus that only works at a reduced rate as an installation defect to be corrected, not as a solution.
Related topics
- Modbus RTUSerial Modbus over RS-485: function codes, register addressing, the off-by-one that catches everyone, and the physical layer details that decide whether a bus is stable.
- Serial CommunicationsRS-232, RS-422, RS-485, biasing, termination, and cable practice.
- Cable Routing ProblemsCable Routing Problems — practical reference notes for controls engineers, integrators, and technicians working with noise & interference.
- Device Times OutDevice Times Out — practical reference notes for controls engineers, integrators, and technicians working with communications troubleshooting.
- Read Works But Write FailsRead Works But Write Fails — practical reference notes for controls engineers, integrators, and technicians working with communications troubleshooting.
- Wrong Register DataWrong Register Data — practical reference notes for controls engineers, integrators, and technicians working with communications troubleshooting.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.