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.
the part worth keeping
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
Getting Started with FRCCommon Mistakes & Troubleshootinglesson 3 of 5
Keep going
Take the quiz+10 XP with an accountMore in Common Mistakes & Troubleshooting
where this came from
Sources and corrections
This lesson is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
sources and further reading
- docs.wpilib.orgCAN Bus Wiring Basics (WPILib)
- chiefdelphi.comThe 2025 Ultimate CAN Bus Thread (Chief Delphi)
- docs.revrobotics.comSPARK MAX Control Interfaces / CAN ID (REV)
clipped to this lesson
Articles that go further on this
The lesson gets you through the topic. These go wider on it, and they read in one sitting.
- 8 min readFRC CAN Bus Explained (and How to Fix Common Problems)How the FRC CAN bus works, the daisy-chain wiring with 120-ohm termination, avoiding device ID conflicts, and fixing the most common CAN failures./blogread it
- 20 min readREV Robotics for FRC: NEO Motors, Spark MAX/Flex, PDH & MAXSwerveA practical guide to the REV Robotics FRC ecosystem: NEO, NEO Vortex and NEO 550 motors, Spark MAX and Spark Flex controllers, the PDH, and MAXSwerve./blogread it
- 18 min readCTRE Phoenix for FRC: Kraken X60/X44, TalonFX, Phoenix 6, CANcoder & Pigeon 2A practical guide to the CTRE Phoenix ecosystem for FRC: Kraken X60/X44 motors, TalonFX, Phoenix 6 API, Pro/FOC licensing, CANcoder, Pigeon 2 & CANivore./blogread it
answer sheet
Lesson quiz
All 3 right completes the lesson. Miss one and only that question comes back, anything you already answered correctly stays banked.
0 of 3 answered
01A CAN device shows up as 'missing' or causes conflicts in Phoenix Tuner X / REV Hardware Client. What CAN addressing rule is most often violated?
02How many 120-ohm termination resistors should a properly wired FRC CAN bus have, and where?
03A loose CAN wire causes devices to intermittently drop off the bus. Which symptom best fits this 'CAN gremlin'?
Answer every question to submit.
All 28 lessons in Getting Started with FRCopenclose
01 / what-first-and-frc-are
02 / the-season-and-the-game
03 / culture-teams-and-roles
04 / getting-started-your-first-steps
05 / worked-examples-mini-projects
- Not read yet:Project 1 — Make a NEO Spin with the REV Hardware Client
- Not read yet:Project 2 — Deploy a Real Arcade-Drive Program
- Not read yet:Project 3 — Refactor into a Command-Based Drive Subsystem
- Not read yet:Project 4 — Build a Fuel Launcher for REBUILT
- Not read yet:Project 5 — A One-Button Autonomous Routine
06 / common-mistakes-troubleshooting
- Not read yet:The Connection Chain: When the Driver Station Won't Connect
- Not read yet:Brownouts: Why the Robot Goes Limp Mid-Match
- Not read yet:CAN Bus Gremlins: Missing and Conflicting Devices
- Not read yet:Software Gotchas: Inverted Drives, Scheduler Stalls, and Reading the RioLog
- Not read yet:Inspection-Day Failures: Bumpers, Size, and Weight
07 / advanced-techniques-case-studies
- Not read yet:Closed-Loop Control: PID + Feedforward for a Consistent Shot
- Not read yet:Swerve Drive: Omnidirectional Movement with YAGSL
- Not read yet:AprilTag Vision: Knowing Where You Are with PhotonVision
- Not read yet:Data-Driven Strategy: Scouting, EPA/OPR, and Alliance Selection
- Not read yet:Choosing Your Hardware Ecosystem: REV vs CTRE