CAN Error Troubleshooting

This document covers troubleshooting common CAN network errors, communication anomalies, and steps to follow when a CAN ID is not found.

Applicable scenarios:

• Klipper reports errors related to CAN0, CAN UUID, or the CAN network.
• CAN device intermittently goes offline or cannot be found.
• You need to troubleshoot CAN bytes_invalid, Timer too close, and other issues.

To configure CAN0, search for CAN IDs, or learn about wiring and terminating resistor rules, please first refer to CAN Network Configuration and ID Search.

Common Error Identification

Error	Common Cause	Solution
OSError: [Errno 19] No such device	Host cannot find the CAN device	Check UTOC, USB cable, CAN bridge firmware, and power supply
can.CanError: Failed to transmit: [Errno 100] Network is down	CAN0 is not started or configured incorrectly	Reconfigure CAN0 and restart
can.CanError: Failed to transmit: [Errno 105] No buffer space available	Insufficient CAN buffer or system network queue anomaly	Confirm buffer is 1024, reconfigure CAN0 if necessary
mcu 'xxx': Invalid CAN uuid	CAN UUID is incorrect or device is offline	Re-scan for UUID, check wiring order, power, and terminating resistors
Serial connection closed	Klipper found the configuration but the connection was interrupted	Check CAN network quality, wiring order, terminating resistors, and firmware rate
Duplicate canbus_uuid	Multiple MCU configurations use the same CAN UUID	Re-scan for UUID, ensure each [mcu xxx] is unique
Unknown canbus_uuid xxx	The configured CAN UUID is not found in the current network scan	Comment out the corresponding MCU configuration, re-scan, and fill in the correct UUID
Can not update MCU 'xxx' config as it is shutdown	CAN MCU entered shutdown first, subsequent config update fails	Scroll up in klippy.log to find the first reason for disconnection or shutdown

For more Klipper errors, refer to Common Error Prompts.

CAN Communication Error Troubleshooting

Electromagnetic Interference is a Common Root Cause

A significant portion of CAN bus communication anomalies is caused by Electromagnetic Interference (EMI). Stepper motor wires, heater wires, and heated bed wires inside a 3D printer generate strong electromagnetic fields when carrying high current. If CAN communication lines (CANH/CANL) are routed closely in parallel with these high-power wires, interference signals can couple onto the CAN bus, leading to:

• Communication timeouts, intermittent MCU disconnection
• Random CAN device offline, canbus_query.py scanning fails
• Timer too close or Communication timeout triggered during homing
• Sudden shutdown during printing with no obvious hardware errors in the log

When troubleshooting interference, first check the routing layout of CAN lines relative to high-power wires, shield grounding, and terminating resistor integrity.

CAN bytes_invalid Counter Continuously Increasing

Error Message: The Stats line logged every second in klippy.log shows bytes_invalid is non-zero and continuously increasing.

Cause: CAN bus messages have been reordered. This is a serious issue that can cause instability and random errors at any stage of a print.

Known Causes:

• Linux kernel version is lower than v6.6.0, which has a gs_usb CAN driver reordering Bug.
• Using a USB-CAN adapter with candlelight firmware, version lower than v2.0.
• Klipper USB-to-CAN bridge mode node firmware is lower than v0.12.0.

Solutions:

1. Upgrade the Linux kernel to v6.6.0 or higher.
2. If using a candlelight USB-CAN adapter, upgrade its firmware to v2.0 or higher.
3. If using Klipper USB-to-CAN bridge mode, ensure the bridge node is flashed with Klipper v0.12.0+ firmware.
4. If bytes_invalid is still increasing, the root cause has not been resolved; continue investigating kernel version and firmware version.
5. Note: An increasing bytes_invalid count is not caused by hardware issues like wiring or terminating resistors; it can only be fixed by updating software/firmware.

CAN Bus Queue Insufficiency Leading to Timer too close

Error Message: MCU 'xxx' shutdown: Timer too close occurs during CAN bus communication.

Cause: The default queue length (qlen) set by the Linux kernel for CAN network interfaces is typically 10, which is too small for Klipper's high-frequency, low-latency communication needs. Klipper official examples often use txqueuelen 128; FlyOS-FAST presets it to 1024, providing more headroom in scenarios with many nodes or high load.

Solutions:

1. Check the current CAN interface queue length:

ip link show can0 | grep qlen

2. Temporarily increase the queue length. Test with 128 for standard systems, use 1024 for FLY systems or machines with multiple nodes:

sudo ip link set dev can0 qlen 128
# or
sudo ip link set dev can0 qlen 1024

3. Permanent setting: Add the txqueuelen 128 or txqueuelen 1024 parameter in /etc/network/interfaces.d/can0; if using systemd-networkd, set TxQueueLength= in the .link file.

CAN Bus Node Not Responding

Error Message: A CAN device suddenly goes offline, canbus_query.py cannot find the device.

Common Causes:

• CAN terminating resistors are missing or incorrect (there must be exactly two 120Ω resistors between CANH-CANL).
• Loose CANH/CANL connections, poor crimping, or loose connectors.
• CAN wire is not twisted shielded pair, or is routed parallel to high-power wires causing EMI (most common and subtle cause).
• Power supply anomaly for the USB-CAN adapter.

Key Points for Interference Troubleshooting:

CAN communication anomalies caused by EMI often appear "intermittent" and "random" – sometimes everything works fine, sometimes it disconnects suddenly, only to recover after a power cycle. Focus on the following when troubleshooting:

• Wiring Layout: Are CAN communication lines routed side-by-side with motor wires, heater wires, or bed wires in cable chains? High-speed PWM modulated motor drive signals and heater switching noise are the strongest interference sources.
• Shield Grounding: If using shielded wire, is the shield grounded at one end only (only on the host side)? Grounding at both ends creates a ground loop, which can introduce interference.
• Terminating Resistor Location: Are the terminating resistors installed at the physical ends of the CAN bus, and enabled via on-board jumpers, DIP switches, or integrated terminal interfaces?
• CAN Cable Specification: Is twisted pair cable used (with a twist pitch of no more than a few centimeters)? Parallel (non-twisted) wires have almost no ability to reject common-mode interference.
• Grounding Integrity: Is the machine's power supply and metal frame reliably grounded? An ungrounded machine frame acts like a large antenna, easily picking up environmental noise.

Troubleshooting Methods:

Power Off Required

The following hardware checks must be performed with the printer completely powered off and disconnected from the power supply: checking CANH/CANL, rerouting wires, adjusting shields, enabling/disabling terminating resistors, measuring CANH-CANL resistance.

1. Confirm there are exactly two 120Ω terminating resistors on the CAN bus. Prioritize using on-board jumpers, DIP switches, or integrated terminal interfaces.
2. Check CANH/CANL connections for tightness and ensure connectors are fully seated.
3. Power off before proceeding. Measure the resistance between CANH-CANL with a multimeter (should be approximately 60Ω).
4. Reroute wires: Separate CAN communication lines from high-power lines, maintaining a distance of at least 2-3 cm, and avoid parallel runs.
5. Verify shield grounding: Ground the shield only on the host side; leave it floating on the tool board side. Do not disassemble the power supply or modify mains grounding.
6. Use candump to monitor CAN bus traffic and observe if a large number of error frames appear.
7. Temporarily reduce print speed/acceleration for testing. If the problem disappears, it suggests interference is positively correlated with motor drive strength.

Troubleshooting Sequence for When an ID is Not Found

1. Execute ip -details link show can0, confirm CAN0 exists and is in a usable state.
2. Confirm that the CAN bitrate in the tool board and mainboard firmware matches the CAN0 bitrate on the host.
3. If the device ID is already written in printer.cfg, temporarily comment out the corresponding configuration, then power off for about 10 seconds before powering back on and searching.
4. Check if CAN-H and CAN-L are swapped, broken, or have poor contact.
5. Confirm there is one 120Ω terminating resistor at each end of the CAN network. Measure the resistance between CAN-H and CAN-L with the machine powered off; it should be approximately 60Ω.
6. Confirm the tool board or mainboard is powered correctly.
7. Confirm the correct communication method was selected during firmware compilation.
8. If the search result shows Application: CANBOOT or Application: Katapult, flash the Klipper firmware first, then search again.

Terminating Resistor Rules

Power Off Required

Before adjusting terminating resistor jumpers, DIP switches, or reconnecting CAN wires, completely shut down the printer and disconnect the power supply.

Device Type	Terminating Resistor Requirement	Operation Instructions
CAN Tool Board	Requires 120Ω terminating resistor	Enable via on-board jumper or DIP switch
Mainboard CAN Interface	Requires 120Ω terminating resistor	Enable via on-board jumper or DIP switch
UTOC type converter module	Usually has a built-in 120Ω resistor	No need to enable an additional terminating resistor

Quick Troubleshooting Sequence

1. Check the device: Execute lsusb, confirm 1d50:606f is visible.
2. Check the configuration: Execute ip -details link show can0, confirm CAN0 exists, bitrate is correct, and buffer is 1024.
3. Check the hardware: Power off completely, then measure between CAN-H and CAN-L, confirm resistance is approximately 60Ω.

If the issue persists after all checks, try swapping USB cables, CAN cables, UTOC, or CAN bridge devices for cross-testing.

CAN Device Firmware Update Reference

This section is for scenarios where the device is already connected to the CAN network and you need to update the firmware of a mainboard or tool board via CAN. Firmware names and compilation methods vary by product; please compile the firmware according to the specific product tutorial first.

Preparation

1. Compile the new firmware according to the product tutorial.
2. Confirm you can find the device's CAN UUID, or that printer.cfg already contains the canbus_uuid: for this device.
3. Stop the Klipper service:

sudo systemctl stop klipper

Performing the Update

Replace <CAN_UUID> in the command below with the actual device ID.

Version Information

Choose the correct command based on your system version.

• FlyOS-FAST 1.3.8 or later or systems with Klipper updated after April 9, 2026:

python3 ~/klipper/lib/katapult/flashtool.py -u <CAN_UUID>

• Older systems, i.e., FlyOS-FAST before 1.3.8, or systems with Klipper not updated before April 9, 2026:

python3 ~/klipper/lib/canboot/flash_can.py -u <CAN_UUID>

Note

There must be a space after -u before entering the CAN UUID.

Seeing the CAN Flash Success prompt usually indicates successful flashing.

Loading...

Post-Update Actions

After the update, restart Klipper:

sudo systemctl start klipper

If you cannot connect after the update, re-scan for the CAN ID and verify that the canbus_uuid: in printer.cfg is still correct.

Final Check List

If you cannot find a CAN ID or Klipper cannot connect to a CAN device, quickly verify the following in order:

1. can0 is recognized by the system.
2. bitrate matches the CAN rate set during firmware compilation.
3. qlen or txqueuelen is 1024.
4. CAN-H and CAN-L are not swapped.
5. Terminating resistors at both ends of the CAN bus are correct.
6. Tool board or mainboard power is normal.
7. Correct communication method is selected in the firmware.
8. printer.cfg uses the actual canbus_uuid: found during scanning.
9. Do not enable both serial: and canbus_uuid: in the same [mcu] section.