CAN Error Troubleshooting

This article covers common CAN network errors, communication anomaly troubleshooting, and the procedure for when a CAN ID cannot be found.

Applicable scenarios:

• Klipper reports errors related to CAN0, CAN UUID, or the CAN network.
• CAN devices intermittently go offline or cannot be found.
• Need to troubleshoot CAN bytes_invalid, Timer too close, and other issues.

If you need to configure CAN0, search for CAN IDs, or learn about wiring and termination resistor rules, please first refer to CAN Network Configuration and ID Search.

Common Error Diagnosis

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 not started or incorrectly configured	Reconfigure CAN0 and restart
can.CanError: Failed to transmit: [Errno 105] No buffer space available	Insufficient CAN buffer or abnormal system network queue	Confirm buffer is 1024, reconfigure CAN0 if necessary
mcu 'xxx': Invalid CAN uuid	Incorrect CAN UUID or device not online	Re-scan for UUID, check wiring order, power supply, and termination resistors
Serial connection closed	Klipper found the configuration but connection was interrupted	Check CAN network quality, wiring order, termination resistors, and firmware baud rate

For more Klipper errors, refer to Common Error Messages.

CAN Communication Error Troubleshooting

Electromagnetic Interference is a Common Root Cause

A significant portion of CAN bus communication anomalies are caused by electromagnetic interference (EMI). Stepper motor wires, heater wires, and heated bed wires inside a 3D printer generate strong electromagnetic fields when operating with high current. If the CAN communication lines (CANH/CANL) are routed closely and 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, failure to scan with canbus_query.py
• Timer too close or Communication timeout triggered during homing
• Sudden shutdown during printing, with no obvious hardware error in the log

When troubleshooting interference, prioritize checking the routing layout of CAN wires relative to high-power wires, shield grounding, and termination resistor integrity.

CAN bytes_invalid Counter Continuously Increasing

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

Cause: CAN bus messages are being reordered. This is a serious issue that can cause instability and random errors at any stage of printing.

Known causes:

• Linux kernel version below v6.6.0 has a gs_usb CAN driver reordering bug.
• USB-CAN adapter using candlelight firmware with version below v2.0.
• Klipper USB-to-CAN bridge mode node firmware below v0.12.0.

Solution:

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 continues to increase, the root cause has not been resolved; continue checking kernel and firmware versions.
5. Note: The increase in bytes_invalid is not caused by hardware issues like wiring or termination resistors; it can only be fixed by updating software/firmware.

Insufficient CAN Bus Queue 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 insufficient for Klipper's high-frequency, low-latency communication needs. Official Klipper examples often use txqueuelen 128; FlyOS-FAST presets it to 1024, providing more headroom in scenarios with many nodes or high loads.

Solution:

1. Check the current CAN interface queue length:

ip link show can0 | grep qlen

2. Temporarily increase the queue length. For standard systems, test with 128; for FLY systems or multi-node machines, use 1024:

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 Unresponsive

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

Common Causes:

• CAN termination resistors are missing or incorrect (there must be exactly two 120Ω resistors between CANH and CANL).
• CANH/CANL wiring is loose, poorly crimped, or the connector is loose.
• CAN cable is not twisted-pair shielded cable, or is routed parallel to high-power wires, causing electromagnetic interference (the most common and subtle cause).
• The USB-CAN adapter has a power supply issue.

Key Points for Interference Troubleshooting:

CAN communication anomalies caused by electromagnetic interference often manifest as "intermittent" and "random" – sometimes everything works fine, other times it suddenly disconnects, only to recover after a power cycle. When troubleshooting, focus on:

• Routing Layout: Are the CAN communication lines routed side-by-side with motor wires, heater wires, or heated bed wires in the cable chain? High-speed PWM-modulated motor drive signals and heater switching noise are the strongest sources of interference.
• Shield Grounding: If using shielded cable, is the shield grounded at only one end (only at the host side)? Grounding at both ends creates a ground loop, which introduces interference instead.
• Termination Resistor Location: Are the termination resistors installed at the physical ends of the CAN bus, enabled via onboard jumper caps, DIP switches, or dedicated termination connectors?
• CAN Cable Specifications: Are you using twisted-pair cable (with a twist pitch of no more than a few centimeters)? Parallel wires (non-twisted) offer almost no suppression of common-mode interference.
• Grounding Integrity: Are the machine's power supply and chassis reliably grounded? An ungrounded machine metal frame acts like a large antenna, easily picking up environmental noise.

Troubleshooting Methods:

Power Off Operation

All hardware checks below must be performed with the printer completely powered off and disconnected from the power supply: checking CANH/CANL, rerouting cables, adjusting shielding, enabling/disabling termination resistors, measuring CANH-CANL resistance.

1. Confirm there are exactly two 120Ω termination resistors on the CAN bus. Prioritize using onboard jumper caps, DIP switches, or dedicated termination connectors.
2. Check if CANH/CANL wiring is secure and connectors are fully inserted.
3. Power off before proceeding. Use a multimeter to measure the resistance between CANH and CANL (normal reading is approximately 60Ω).
4. Reroute cables: Separate CAN communication lines from high-power wires, maintaining at least 2-3cm distance, and avoid parallel runs.
5. Verify shield grounding: The shield should only be grounded on the host side; leave it floating on the toolhead board side. Do not disassemble the power supply or modify the mains ground wire on your own.
6. Use candump to monitor CAN bus traffic, checking for a high number of error frames.
7. Temporarily reduce print speed/acceleration for testing; if the problem disappears, interference is positively correlated with motor drive intensity.

Troubleshooting Sequence When ID Not Found

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

Termination Resistor Rules

Power Off Operation

Before adjusting terminal resistor jumper caps, DIP switches, or re-plugging CAN cables, completely shut down the printer and disconnect the power supply.

Device Type	Termination Resistor Requirement	Operation Instructions
CAN Tool Board	Requires 120Ω termination resistor	Enable via onboard jumper cap or DIP switch
Mainboard CAN Interface	Requires 120Ω termination resistor	Enable via onboard jumper cap or DIP switch
UTOC Type Converter Module	Usually has a built-in 120Ω resistor	No need to add an external termination resistor

Quick Troubleshooting Sequence

1. Check the device: Run lsusb and confirm you can see 1d50:606f.
2. Check the configuration: Run ip -details link show can0 and confirm CAN0 exists, the baud rate is correct, and the buffer is 1024.
3. Check the hardware: With the machine completely powered off, measure CAN-H and CAN-L to confirm the 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 you can already connect to the CAN network and need to update the mainboard or tool board firmware via CAN. The firmware name and compilation method vary by product; please compile the firmware according to the respective product tutorial first.

Preparation

1. Compile the new firmware according to the product tutorial.
2. Confirm you can scan the device's CAN UUID, or that you have already filled in the device's canbus_uuid: in printer.cfg.
3. Stop the Klipper service:

sudo systemctl stop klipper

Execute the Update

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

Version Information

Choose the command based on your system version.

• FlyOS-FAST 1.3.8 and above or system with Klipper updated after April 9, 2026:

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

• Older system versions, i.e., before FlyOS-FAST 1.3.8, or systems where Klipper was 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.

A prompt indicating CAN Flash Success usually means the flashing was successful.

Loading...

Post-Update Operations

After the update is complete, restart Klipper:

sudo systemctl start klipper

If you cannot connect after the update, rescan for the CAN ID and confirm that the canbus_uuid: in printer.cfg is still correct.

Final Checklist

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 baud rate set during firmware compilation.
3. qlen or txqueuelen is 1024.
4. CAN-H and CAN-L are not reversed.
5. Termination resistors are correctly installed at both ends of the CAN bus.
6. The tool board or mainboard has a normal power supply.
7. The correct communication method was selected for the firmware.
8. The canbus_uuid: used in printer.cfg matches the one actually scanned.
9. The same [mcu] section does not have both serial: and canbus_uuid: enabled.