CAN Bus Failures: Intermittent Devices and Dropped Comms

CAN problems are maddening because they are intermittent: a device works on the bench, then disappears after a hard hit. The bus is a daisy chain, so one bad connection can take down everything downstream of it. Here is how to hunt them.

Topology first. CAN should daisy-chain from the roboRIO, into and out of each device in turn, ending at the PD. Yellow is CANH, green is CANL, and the pair should be twisted. The network needs a 120 ohm termination resistor at each physical end; these are built into the roboRIO and the CTRE PDP (the PDP's jumper ships ON). Put all other CAN nodes between the roboRIO and the PD so both ends stay terminated. Missing or doubled termination causes flaky, unexplainable dropouts.

The jostle test for loose wires. Power the robot, watch the CAN device LEDs (orange = healthy/idle on CTRE), and physically flick, shake, and jostle the harness in sections. A red blip on any device the instant you move a segment localizes a loose contact to that segment. WAGO/Weidmuller spring terminals are the usual culprits: a wire that was tinned or twisted before insertion will back out. Re-strip to bare, untinned, untwisted copper and reinsert.

ID conflicts. Each device needs a unique ID. CTRE device IDs run 0-62. Two devices sharing an ID will fight and one or both will misbehave. Symptom: a motor that responds erratically or a device that vanishes when another is connected. Fix by connecting suspects one at a time in Phoenix Tuner X / REV Hardware Client and reassigning IDs, then documenting them in a CAN map.

Firmware mismatch. A device whose firmware does not match your Phoenix 6 / REVLib 2025 vendordep version may report as unlicensed or unresponsive. Update firmware in Tuner X / Hardware Client to match.

Over-utilization. Too many devices or too-fast status frames saturate the bus. Keep utilization comfortably below saturation (a commonly cited target is under ~70%); above that you get lost packets and errors. Check it via the DS or CANBus.getStatus(). If you are high, reduce status frame rates or move devices to a CANivore CAN FD bus (see the advanced module).

Debug workflow:

1. Confirm termination at both ends.
2. Jostle-test for loose connections; re-seat any spring terminals with bare untinned wire.
3. In Tuner X/Hardware Client, confirm every device is present with a unique ID and matching firmware.
4. Reintroduce devices one at a time until the failure reappears; scrutinize that device's wire, power, and ID.
5. Check utilization; trim frame rates if it is high.