CAN Bus Gremlins: Missing and Conflicting Devices
Find dropped CAN devices, duplicate IDs, and broken termination using REV Hardware Client and Phoenix Tuner X.
Sign in to track progress, earn XP, and save lessons.
CAN bus issues are notorious because they are intermittent — a device works on the bench, then disappears when the robot vibrates on the field. CAN connects all your smart devices (SPARK MAX, TalonFX/Kraken, CANcoder, Pigeon 2.0, PDH) on a single twisted-pair daisy chain.
Symptom: a device is 'not found' or motors randomly stop. Diagnose systematically:
- Check for duplicate IDs. Two devices sharing a CAN ID is the classic killer — SPARK MAX and many CTRE devices ship as ID 0 from the factory. Open the REV Hardware Client (for SPARK MAX) and Phoenix Tuner X (for CTRE devices); each scans the bus and lists every device with its ID. A device that flickers in and out, or two devices fighting over one ID, jumps out immediately. Reassign every device to a unique ID and persist it.
- Check the wiring topology. CAN must be a single daisy chain (yellow to yellow, green to green) from the roboRIO through every device to the PDH. A common rookie mistake is wiring it as a star/parallel splice instead of a series chain. Tug every connector — vibration loosens cheap crimps, and one loose joint downstream drops every device after it.
- Check termination. The bus needs a 120-ohm resistor at each physical end. The roboRIO has one built in; the PDH/PDP provides the other (often via a switch or jumper). Missing termination makes the bus marginal — it works at rest and fails under vibration.
Read the faults. The Driver Station and the device tools report sticky faults. A 'No CAN Comm' / loss-of-CAN fault means the device cannot talk over the bus. High CAN bus utilization (visible in the DS) means you are flooding the bus — reduce status-frame rates on devices you poll rarely.
The reliability habit veterans swear by: label every CAN ID on a wiring diagram and physically on the device, keep a spare 120-ohm terminator in the pit, and after any chassis work, re-scan the full bus in both tools before driving. A robot that loses CAN mid-match can lose the match outright, so treat clean CAN wiring as a competitive requirement, not a nicety.
Key takeaways
- Duplicate CAN IDs (SPARK MAX and many CTRE devices ship as 0) are the #1 cause of missing devices — give each a unique ID and persist it
- CAN must be a single daisy chain with 120-ohm termination at each end; a star topology or loose connector drops everything downstream
- Re-scan the full bus in REV Hardware Client and Phoenix Tuner X after any chassis work, and label every ID
Go deeper
Lesson quiz
RequiredAnswer all 3 questions correctly to complete this lesson.
1.A CAN device shows up as 'missing' or causes conflicts in Phoenix Tuner / REV Hardware Client. What CAN addressing rule is most often violated?
2.How many 120-ohm termination resistors should a properly wired FRC CAN bus have, and where?
3.A loose CAN wire causes devices to intermittently drop off the bus. Which symptom best fits this 'CAN gremlin'?
Answer every question to submit.