How to Troubleshoot a CAN Bus
A CAN bus that has stopped communicating, or that works most of the time and drops out under load, is one of the more common field calls on machine, engine, and genset systems. The good news is that CAN failures fall into a short list of causes and there is an efficient order to check them, from the cheapest measurement to the most involved. This procedure walks that order: confirm termination first, verify the baud rate, inspect wiring and grounds, then read the error counters to localize the culprit.
Troubleshoot a CAN Bus in one line: To troubleshoot a CAN bus, work cheapest first: with power off, measure CAN_H to CAN_L resistance and confirm about 60 ohms for correct termination; then verify every node shares one baud rate; then inspect wiring, connectors, stub lengths, and grounding; and finally read the error counters on an analyzer to see which node is generating errors or has gone bus-off. Most CAN faults are physical-layer, not software.
What You Need
Gather a digital multimeter for resistance and voltage, a CAN bus analyzer or a controller with error-counter visibility, and the network documentation that lists each node, its baud rate, and where the two terminators belong. If you have an oscilloscope with the right probes it helps for edge-quality problems, but most CAN faults are found and fixed with the multimeter and analyzer alone.
Before touching anything, note the symptom precisely: total silence versus intermittent dropouts, one node missing versus all nodes gone, and whether the fault correlates with load, temperature, vibration, or a recent change. A bus that died right after a device was swapped points at that device; a bus that fails only when a machine runs points at noise or a vibrating connection. The symptom shape narrows the search before the first measurement.
Check Termination Resistance First
Power the bus down and measure resistance between CAN_H and CAN_L. A correctly terminated bus reads close to 60 ohms because its two 120 ohm terminators are in parallel. This one measurement resolves a large share of CAN faults immediately, which is why it comes first.
Read the result against the expectations for CAN bus termination: about 120 ohms means a terminator is missing at one end, about 40 ohms means an extra terminator has been added, near zero means a short between the conductors, and open or very high means a break in the bus or both terminators absent. Fix whatever the number reveals before going further, because a termination problem will masquerade as every other kind of fault if you leave it in place.
Verify Every Node Shares One Baud Rate
Confirm from the documentation and from each device's configuration that every node is set to the same baud rate. A single node at the wrong rate misreads bit boundaries and floods the bus with error frames, so it does not just go quiet, it disrupts everyone. This is the prime suspect when a bus stopped working immediately after a device was added or replaced.
If a protocol fixes the rate, such as J1939 at 250 kbit/s, confirm the new or reconfigured device actually landed on that rate rather than a default it shipped with. Devices with automatic bit-rate detection can also get stuck if they never see valid traffic to lock onto, so verifying the rate explicitly is safer than trusting auto-detection when a bus is already broken. The mechanics of the trade-off are covered under CAN baud rate and cable length.
Inspect Wiring, Connectors, and Grounds
With termination and rate ruled out, the fault is usually mechanical. Inspect connectors for looseness, corrosion, and back-out pins; check that stub lengths off the backbone are short, since long drops cause reflections that get worse at higher rates; and confirm the bus is a single linear backbone rather than a star, which CAN tolerates poorly. Vibration and thermal cycling loosen connections over time, which is why an intermittent fault that tracks machine operation so often lives in a connector.
Check grounding and shielding next. A large ground-potential difference between distant nodes stresses the transceivers and shows up as errors that come and go with plant conditions. Confirm the shield is handled per the network's grounding scheme and that no node is missing its ground reference. These physical-layer issues are the same family of problems you would chase on an RS-485 serial network, and they respond to the same disciplined inspection.
Read Error Counters to Localize the Culprit
Finally, connect the analyzer and watch the error counters and states. A specific node piling up transmit errors, dropping to error-passive, or cycling into bus-off is pointing at itself: its transceiver, its drop wiring, or its connector. Watch which node's counter climbs and you have localized the fault to one device rather than the whole bus, using the states described under CAN error frames and the bus-off state.
Distinguish the error types too. A high stuff-error or CRC-error count points at noise and physical corruption; a high acknowledgment-error count on one transmitter can mean it is alone on the bus or the others cannot hear it. Reading the mix of errors turns a vague dropout into a specific hypothesis you can confirm at the wire, which is where CAN faults are almost always fixed.
Verifying the Result
After a fix, confirm it two ways. First, re-measure the 60 ohm termination if you touched wiring, and watch the analyzer error counters hold at or near zero under the same load that triggered the fault, including running the machine if the fault was load-dependent. A fix that only holds at idle has not been proven.
Second, watch the data recover upstream. If the bus feeds a monitoring system through a gateway, confirm the previously missing node's tags return and hold steady in the time-series trend over a representative run. Watching the trend stay clean after the repair is how you prove the fault is actually gone rather than merely quiet for the moment.
Common Mistakes
The most common mistake is skipping the termination check and going straight to software or device configuration, which wastes hours on a fault a multimeter would have found in a minute. The second is measuring termination with the bus powered, which reads live drivers instead of the resistors and gives a meaningless number. Always power down for the resistance check.
Other recurring errors are assuming all nodes share a baud rate without verifying the one that was just changed, treating an intermittent load-dependent dropout as a software bug when it is a vibrating connector, and declaring victory at idle without recreating the load that caused the failure. CAN faults reward patience and the cheapest-first order; jumping to the exotic explanation before ruling out termination, rate, and connectors is how straightforward faults become long ones.
Frequently Asked Questions
My CAN bus is not communicating at all, where do I start?
Start with termination. Power the bus down and measure resistance between CAN_H and CAN_L; a correct bus reads about 60 ohms. About 120 ohms means a missing terminator, about 40 ohms means an extra one, near zero is a short, and open is a break or both terminators missing. This single measurement resolves a large fraction of dead-bus faults before you touch any device configuration.
Why does my CAN bus only drop out when the machine runs?
A load- or run-dependent dropout usually points at the physical layer: a connector loosened by vibration, a marginal ground that shifts when high-current equipment runs, or noise coupling that only appears under load. Check connectors and stub lengths, verify grounding and shielding, and watch error counters on an analyzer while the machine runs, since the culprit node's transmit-error count will climb during the fault.
How do error counters help find a bad CAN node?
CAN controllers weight transmit errors toward the node that is actually failing, so the device whose transmit-error counter climbs, drops to error-passive, or goes bus-off is usually the culprit rather than a bystander. Watching which single node's counter rises on an analyzer localizes the fault to one device's transceiver, drop wiring, or connector, turning a vague bus dropout into a specific place to inspect.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.