Skip to content
Electrical & Wiring·Lesson 27 of 34

CAN Bus Failures: Intermittent Devices and Dropped Comms

Find and fix the loose connections, ID conflicts, missing termination, and over-utilization that kill CAN devices.

Sign in to track progress, earn XP, and save lessons.

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.

Key takeaways

  • CAN is a daisy chain needing 120 ohm termination at both physical ends (built into the roboRIO and CTRE PDP); keep other nodes in between.
  • The jostle test localizes loose connections; never tin or pre-twist wire going into WAGO/Weidmuller spring terminals.
  • Keep bus utilization well below saturation and ensure unique IDs (0-62 for CTRE) and matching firmware via Tuner X / REV Hardware Client.

Go deeper

Lesson quiz

Required

Answer all 3 questions correctly to complete this lesson.

1.An FRC CAN bus requires terminating resistors at each end. What value are they, and where are the two standard ones located?

2.In FRC CAN wiring, which colors correspond to CAN-High and CAN-Low?

3.A motor controller intermittently drops off the CAN bus. Which is a likely cause consistent with proper CAN troubleshooting?

Answer every question to submit.