CAN Error Troubleshooting

This document covers common CAN network errors, communication anomaly troubleshooting, and procedures 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 issues like bytes_invalid, USB CANBUS bridge, BUS-OFF, Timer too close.

If you need to configure CAN0, search for a CAN ID, or understand 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 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 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	Incorrect CAN UUID or device not online	Re-search 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
Duplicate canbus_uuid	Multiple MCU configurations use the same CAN UUID	Re-search for UUID, ensure each [mcu xxx] is unique
Unknown canbus_uuid xxx	CAN UUID in config not found in current network scan	Comment out the corresponding MCU config, 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 failed	Scroll up in klippy.log to find the root cause of the first disconnection or shutdown
USB CANBUS bridge 'mcu' is discarding!	USB-CAN bridge MCU's CAN hardware has discarded messages	Check canstat_mcu, bus_state, power supply, transceiver, and wiring harness
can state BUS-OFF / ERROR-PASSIVE	CAN controller entered an error state	Power off and check the physical bus, termination resistors, wiring order, and number of nodes

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 during high-current operation. If the CAN communication lines (CANH/CANL) are routed closely parallel to these high-power wires, interference signals can couple onto the CAN bus, leading to:

• Communication timeouts, intermittent MCU disconnections
• Random CAN device offline, canbus_query.py scan failures
• Timer too close or Communication timeout triggered during homing
• Sudden shutdown during printing with no obvious hardware error in logs

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

CAN bytes_invalid Counter Continuously Increases

Error Message: The Stats line in klippy.log shows bytes_invalid is 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 during printing.

Known causes:

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

Solution:

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

Timer too close Due to Insufficient CAN Bus Queue

Error Message: MCU 'xxx' shutdown: Timer too close 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.

Solution:

1. Check the current CAN interface queue length:

ip link show can0 | grep qlen

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

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

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

USB CANBUS bridge is discarding / bus_state=off

Error Message: USB CANBUS bridge 'mcu' is discarding!, canstat_mcu: bus_state=off, can state BUS-OFF, ERROR-PASSIVE, followed by Timeout with MCU 'xxx' or Serial connection closed.

Cause: The CAN hardware of the USB-CAN bridge MCU has stopped sending or receiving messages properly. This is usually not simply due to insufficient txqueuelen; it is more often caused by poor CAN wiring harness contact, incorrect termination resistor placement, a faulty transceiver or node, power fluctuations on the toolhead board, or a bus that is too long or has too many nodes leading to insufficient signal margin.

Troubleshooting Steps:

Power Off

Before checking CANH/CANL, re-seating toolhead boards, adjusting termination resistors, or measuring CANH-CANL resistance, completely shut down the printer and disconnect the power supply. Do not add or remove CAN nodes or plug/unplug toolhead board harnesses while the system is powered on.

1. Find the Stats lines around USB CANBUS bridge 'mcu' is discarding! in klippy.log. Record the bus_state, rx_error, tx_error, and tx_retries from canstat_mcu.
2. If bus_state changes from active to off or passive, prioritize troubleshooting as a hardware bus issue. Do not just adjust the Linux queue length.
3. After powering off, confirm there are exactly two termination resistors on the CAN bus, located at the physical ends of the bus. The measured resistance between CANH and CANL should typically be close to 60Ω.
4. Test by reducing the number of CAN nodes one by one: start with only the mainboard and one toolhead board, then gradually add nodes. Determine if a specific toolhead board, wiring harness, or branch triggers the anomaly upon connection.
5. Check the toolhead board's power supply and connector crimp quality. If a toolhead board resets, the bridge side might show discarding first, before other MCUs are reported as timeout.
6. For machines with multiple toolheads or long cable runs, temporarily test with a lower CAN baud rate, or split the toolheads across two USB-CAN adapters for cross-validation.
7. If the issue persists after updating Klipper and all CAN node firmware, test by replacing the CAN cable, USB-CAN adapter, or toolhead board transceiver module.

Only Partial CAN Node UUIDs Found

Error Message: canbus_query.py can only find UUIDs for some toolhead boards. Or, on the same CAN bus, one or two nodes work fine, but when a third or more nodes are added, none can be found, connections time out, or BUS-OFF occurs.

Common Causes:

• The newly added toolhead board is not in Katapult / Klipper CAN mode, or its firmware CAN baud rate differs from the host's can0 setting.
• A node has CANH/CANL reversed, poor crimping, or a damaged transceiver, dragging down the entire bus.
• Termination resistors are not at the physical ends of the bus, or an extra termination resistor is enabled by mistake on a toolhead board, hub board, or adapter.
• Multi-toolhead wiring harnesses form excessively long loops, star branches, or impedance discontinuities. Signal margin becomes insufficient as the number of nodes increases.
• Different batches of toolhead boards use different bootloaders, Katapult, or Klipper firmware, leading to inconsistent search states.

Troubleshooting Steps:

Power Off

Before adding or removing CAN nodes, adjusting termination resistors, re-crimping wiring harnesses, or measuring CANH-CANL resistance, completely shut down the printer and disconnect the power supply.

1. Keep only the host CAN interface and one target toolhead board. Confirm that a single node can be found with its UUID.
2. Systematically replace short cables, ports, and toolhead boards to isolate whether the issue is with a specific node or only appears when the node count increases.
3. Verify the bootloader, Klipper firmware communication method, and CAN baud rate for each toolhead board. Ensure all nodes are consistent with can0.
4. Confirm that the canbus_uuid for each [mcu xxx] is unique. If a device's UUID is already written in the config, temporarily comment out the corresponding MCU section and restart Klipper before searching.
5. With the power off, measure the resistance between CANH and CANL. A value of approximately 60Ω usually indicates two 120Ω termination resistors at each end. If the value deviates significantly, correct the termination resistor issue first.
6. If any two nodes are stable but three or more are unstable, prioritize checking the bus topology, cable length, termination placement, and hub board documentation. If necessary, split the network into two CAN buses.

CAN Bus Node Does Not Respond

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

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, has poor crimping, or the connector is loose.
• The CAN cable is not twisted-pair shielded, or is routed parallel to high-power wires causing electromagnetic interference (the most common and insidious cause).
• USB-CAN adapter power supply is faulty.

Key Points for Interference Investigation:

EMI-induced CAN communication anomalies tend to be "intermittent" and "random"—sometimes everything works fine, sometimes it suddenly disconnects, only to recover after a power cycle. When investigating, focus on:

• Cable Routing: Are the CAN communication lines routed side-by-side in the cable chain with motor cables, heater cables, or heated bed cables? The 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 one end only (typically at the host side)? Double-ended grounding creates a ground loop, which can introduce interference instead of preventing it.
• 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 Specification: Is twisted-pair cable used (with a twist pitch of no more than a few centimeters)? Parallel (non-twisted) wiring offers very little suppression of common-mode interference.
• Ground Integrity: Is the machine's power supply and chassis properly grounded? An ungrounded machine's metal frame acts like a large antenna, picking up environmental noise.

Troubleshooting Steps:

Power Off

The following hardware checks must be performed with the printer completely shut down and disconnected from the power supply: checking CANH/CANL, re-routing cables, adjusting the shield, enabling/disabling termination resistors, and measuring CANH-CANL resistance.

1. Confirm there are exactly two 120Ω termination resistors on the CAN bus. Prefer using onboard jumper caps, DIP switches, or dedicated terminal interfaces.
2. Check that 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 value is approx. 60Ω).
4. Re-route cables: Separate the CAN communication lines from high-power wires, maintaining at least a 2-3cm distance. Avoid parallel runs.
5. Confirm shield grounding: The shield should only be grounded at the host side; leave it floating at the toolhead board side. Do not disassemble the power supply or modify the mains ground wire yourself.
6. Use candump to monitor CAN bus traffic. Observe if a large number of error frames appear.
7. Temporarily lower print speed/acceleration to test. If the problem disappears, it strongly suggests interference is correlated with motor drive intensity.

Search Order When Unable to Find an ID

1. Execute ip -details link show can0 to confirm CAN0 exists and is in an available state.
2. Verify the CAN baud rate in the toolhead/mainboard firmware matches the host's CAN0 baud rate.
3. If the device ID is already written in printer.cfg, temporarily comment out the corresponding configuration section. Power off the machine for about 10 seconds, then power it back on before searching again.
4. Check if CAN-H and CAN-L are reversed, broken, or have poor contact.
5. Ensure there is one 120Ω termination 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 toolhead board or mainboard is receiving power correctly.
7. Confirm the correct communication method was selected when compiling the firmware.
8. If the search result shows Application: CANBOOT or Application: Katapult, please flash the Klipper firmware first, then search again.

Termination Resistor Rules

Power Off

Before adjusting termination resistor jumper caps, DIP switches, or reconnecting CAN cables, completely shut down the printer and disconnect the power supply.

Device Type	Termination Resistor Requirement	Explanation
CAN Toolhead 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 120Ω resistor built-in	No need to add an extra termination resistor

Quick Troubleshooting Sequence

1. Check the device: Execute lsusb to confirm a device with the ID 1d50:606f is visible.
2. Check the configuration: Execute ip -details link show can0 to confirm CAN0 exists, the baud rate is correct, and the buffer size is 1024.
3. Check the hardware: With the power completely off, measure the resistance between CAN-H and CAN-L. Confirm it is approximately 60Ω.

If the issue persists after all checks, try cross-testing by replacing the USB cable, CAN cable, UTOC, or CAN bridge device.

CAN Device Firmware Update Reference

This section is for scenarios where the device is already connected to the CAN network and needs a firmware update via CAN for the mainboard or a toolhead board. The firmware name and compilation method 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 the device's CAN UUID can be found, or it is already entered as canbus_uuid: in printer.cfg for the specific 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 command based on your system version.

• FlyOS-FAST 1.3.8 and later or systems where Klipper was 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 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 CAN Flash Success message usually indicates successful flashing.

Loading...

Post-Update Actions

After the update is complete, restart Klipper:

sudo systemctl start klipper

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

Final Checklist

When unable to 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 swapped.
5. Termination resistors are correctly placed at both ends of the CAN bus.
6. Toolhead board or mainboard is powered correctly.
7. The firmware's communication method is selected correctly.
8. printer.cfg uses the actual canbus_uuid: found during the search.
9. The same [mcu] section does not have both serial: and canbus_uuid: enabled simultaneously.