CAN エラー調査

本記事では、CANネットワークの一般的なエラー、通信異常の調査、およびCAN IDが見つからない場合の調査手順について説明します。

適用シーン：

• Klipper で CAN0、CAN UUID または CAN ネットワーク関連エラーが発生する場合。
• CAN デバイスが断続的にオフラインになる、または検索できない場合。
• CAN bytes_invalid、USB CANBUS bridge、BUS-OFF、Timer too close などの問題を調査する必要がある場合。

CAN0 の設定、CAN ID の検索、または配線と終端抵抗のルールについては、先に CAN ネットワーク設定と ID 検索 を参照してください。

よくあるエラーの判断

エラー	一般的な原因	対処方法
OSError: [Errno 19] No such device	ホストコンピューターが CAN デバイスを見つけられない	UTOC、USB ケーブル、CAN ブリッジファームウェア、電源を確認
can.CanError: Failed to transmit: [Errno 100] Network is down	CAN0 が起動していない、または設定が間違っている	CAN0 を再設定して再起動
can.CanError: Failed to transmit: [Errno 105] No buffer space available	CAN バッファ不足またはシステムネットワークキュー異常	バッファが 1024 であることを確認し、必要に応じて CAN0 を再設定
mcu 'xxx': Invalid CAN uuid	CAN UUID の記述誤り、またはデバイスがオンラインでない	UUID を再検索し、線順序、電源、終端抵抗を確認
Serial connection closed	Klipper が設定を見つけたが接続が切断された	CAN ネットワーク品質、線順序、終端抵抗、ファームウェア速度を確認
Duplicate canbus_uuid	複数の MCU 設定が同じ CAN UUID を使用している	UUID を再検索し、各 [mcu xxx] が一意であることを確認
Unknown canbus_uuid xxx	設定内の CAN UUID が現在のネットワーク検索結果にない	該当 MCU 設定をコメントアウトして再検索し、記入
Can not update MCU 'xxx' config as it is shutdown	CAN MCU が先にシャットダウンし、後続の設定更新に失敗	klippy.log を遡り、最初の切断またはシャットダウンの根本原因を確認
USB CANBUS bridge 'mcu' is discarding!	USB-CAN ブリッジ MCU の CAN ハードウェアがメッセージを破棄	canstat_mcu、bus_state、電源、トランシーバー、配線を確認
can state BUS-OFF / ERROR-PASSIVE	CAN コントローラーがエラー状態に入った	電源を切り、物理バス、終端抵抗、線順序、ノード数を確認

その他の Klipper エラーについては、よくあるエラー表示 を参照してください。

CAN 通信エラー調査

電磁妨害は一般的な原因です

CAN バス通信異常の大きな原因の一つは電磁妨害（EMI）です。3Dプリンター内部のステッピングモーターケーブル、ヒーターケーブル、ヒートベッドケーブルは大電流動作時に強力な電磁界を発生します。CAN 通信線（CANH/CANL）がこれらの強電線と近接して平行配線されていると、妨害信号が CAN バスに結合し、以下の原因となります：

• 通信タイムアウト、MCU の断続的なオフライン
• CAN デバイスのランダムなオフライン、canbus_query.py でのスキャン不可
• ホーミング中の Timer too close または Communication timeout の発生
• 印刷中の突然のシャットダウン、ログに明確なハードウェアエラーなし

妨害調査時は、CAN 線と強電線の配線レイアウト、シールド層の接地、終端抵抗の完全性を優先的に確認してください。

CAN bytes_invalid カウンターが持続的に増加

エラーメッセージ：klippy.log の毎秒統計行 Stats に bytes_invalid が非ゼロで持続的に増加している。

エラー原因：CAN バスのメッセージが並べ替えられ（reordered messages）ている。これは深刻な問題で、印刷プロセスのどの段階でも不安定さやランダムエラーを引き起こす可能性があります。

既知の原因：

• Linux カーネルバージョンが v6.6.0 未満で、gs_usb CAN ドライバーの並べ替えバグが存在する。
• candlelight ファームウェアの USB-CAN アダプターで、ファームウェアバージョンが v2.0 未満。
• Klipper USB-to-CAN ブリッジモードノードのファームウェアが v0.12.0 未満。

解決方法：

1. candlelight USB-CAN アダプターを使用している場合、ファームウェアを v2.0 以上にアップグレードする。
2. Klipper USB-to-CAN ブリッジモードを使用している場合、ブリッジノードに Klipper v0.12.0+ ファームウェアを書き込むことを確認する。
3. それでも bytes_invalid が増加する場合、根本原因が解決されていないため、カーネルバージョンとファームウェアバージョンの調査を継続する必要がある。
4. 注意：bytes_invalid の増加は、配線や終端抵抗などのハードウェア問題によって引き起こされるものではなく、ソフトウェア/ファームウェアの更新によってのみ修正可能です。

CAN バスキュー不足による Timer too close

エラーメッセージ：CAN バス通信時に MCU 'xxx' shutdown: Timer too close が発生。

エラー原因：Linux カーネルが CAN ネットワークインターフェースに設定するデフォルトのキュー長（qlen）は通常 10 で、Klipper の高頻度低遅延通信要件には小さすぎます。Klipper 公式サンプルでは txqueuelen 128 がよく使われます。FlyOS-FAST は 1024 にプリセットされており、ノード数が多い場合や高負荷シナリオで余裕があります。

解決方法：

1. 現在の CAN インターフェースのキュー長を確認：

ip link show can0 | grep qlen

2. 一時的にキュー長を増やす。通常のシステムでは最初に 128 をテストし、FLY システムやマルチノードマシンでは 1024 を使用：

sudo ip link set dev can0 qlen 128
# または
sudo ip link set dev can0 qlen 1024

3. 永続的に設定：/etc/network/interfaces.d/can0 に txqueuelen 128 または txqueuelen 1024 パラメータを追加；systemd-networkd を使用する場合は .link ファイルに TxQueueLength= を設定。

USB CANBUS bridge is discarding / bus_state=off

エラーメッセージ：USB CANBUS bridge 'mcu' is discarding!、canstat_mcu: bus_state=off、can state BUS-OFF、ERROR-PASSIVE、その後 Timeout with MCU 'xxx' または Serial connection closed が発生。

エラー原因：USB-CAN ブリッジ MCU の CAN ハードウェアが正常な送受信を停止している。通常、単純な txqueuelen 不足ではありません。より一般的な原因は、CAN 配線の接触不良、終端抵抗の位置間違い、トランシーバーまたは特定ノードの異常、ツールボードの電源変動、バスが長すぎる、またはノード数が多すぎて信号マージンが不足していることです。

調査方法：

電源オフ操作

CANH/CANL の確認、ツールボードの抜き差し、終端抵抗の調整、または CANH-CANL 抵抗の測定を行う前は、プリンターの電源を完全に切り、電源供給を切断してください。通電状態で CAN ノードを追加/削除したり、ツールボードの配線を抜き差ししないでください。

1. klippy.log で USB CANBUS bridge 'mcu' is discarding! 前後の Stats 行を見つけ、canstat_mcu の bus_state、rx_error、tx_error、tx_retries を記録する。
2. bus_state が active から off または passive に変わった場合、ハードウェアバスの問題として優先的に調査し、Linux キューの長さだけを調整しない。
3. 電源を切った後、CAN バス上に終端抵抗が2つだけあり、物理バスの両端にあることを確認。測定される CANH-CANL 抵抗値は通常約 60Ω になるはず。
4. CAN ノードを一つずつ減らしてテスト：最初はメインボードと1つのツールボードのみ保持し、徐々にノードを追加。特定のツールボード、配線、または分岐が接続されたときに異常が発生するか確認する。
5. ツールボードの電源とコネクタの圧着状態を確認。特定のツールボードがリセットされた場合、ブリッジ側で最初に discarding が発生し、その後他の MCU がタイムアウトとして報告される可能性がある。
6. マルチツールヘッドまたは長い配線のマシンでは、一時的に CAN レートを下げてテストするか、複数のツールヘッドを2つの USB-CAN アダプターに分けてクロス検証する。
7. Klipper と全ての CAN ノードファームウェアを更新しても再現する場合、市販の CAN ケーブル、USB-CAN アダプター、またはツールボードのトランシバーモジュールを交換してクロス検証する。

マルチ CAN ノードの一部のみ UUID を検出

エラーメッセージ：canbus_query.py で一部のツールボード UUID しか検出できない、または同じ CAN バス上の任意の1～2ノードは正常だが、3つ目以降のノードを追加すると全て検出不可、接続タイムアウト、BUS-OFF になる。

一般的な原因：

• 追加したツールボードが Katapult / Klipper CAN モードになっていない、またはファームウェアの CAN レートがホストの can0 と一致していない。
• 特定ノードの CANH/CANL が逆接続、圧着不良、トランシーバー損傷により、接続後にバス全体がダウンする。
• 終端抵抗が物理バスの両端にない、またはツールボード、ハブボード、アダプターボードで余分な終端抵抗が誤って有効になっている。
• マルチツールヘッド配線が長すぎるループ、スター型分岐、またはインピーダンス不連続を形成し、ノード数増加後に信号マージンが不足する。
• 異なるバッチのツールボードが異なるブートローダー、Katapult、または Klipper ファームウェアを使用しており、検索状態が一致しない。

調査方法：

電源オフ操作

CAN ノードの追加/削除、終端抵抗の調整、配線の再圧着、または CANH-CANL 抵抗の測定を行う前は、プリンターの電源を完全に切り、電源供給を切断してください。

1. ホストの CAN インターフェースと1つの対象ツールボードのみを残し、単一ノードで UUID が検出できることを確認する。
2. 短いケーブル、ポート、ツールボードを一つずつ交換し、特定のノードの問題か、ノード数が増えた後にのみ発生する問題かを確認する。
3. 各ツールボードのブートローダー、Klipper ファームウェアの通信方式、CAN レートを確認し、全てのノードが can0 と一致していることを確認する。
4. 各 [mcu xxx] の canbus_uuid が一意であることを確認。デバイスが既に設定に書き込まれている場合、検索前に一時的に該当 MCU 設定をコメントアウトし、Klipper を再起動する。
5. 電源を切って CANH-CANL 間の抵抗を測定。約 60Ω の場合、通常は両端にそれぞれ 120Ω の終端抵抗があることを示します。大きく外れている場合は、まず終端抵抗を処理する。
6. 任意の2ノードは安定しているが、3つ以上で不安定になる場合、バストポロジー、ケーブル長、終端位置、ハブボードの説明書を優先的に確認。必要に応じて2つの CAN バスに分割する。

CAN バスノードが応答しない

エラーメッセージ：CAN デバイスが突然オフラインになり、canbus_query.py でデバイスをスキャンできない。

一般的な原因：

• CAN 終端抵抗がない、または正しくない（CANH-CANL 間には 120Ω 抵抗が厳密に2つ必要）。
• CANH/CANL の配線緩み、圧着不良、またはコネクタの緩み。
• CAN ケーブルがツイストペアシールド線でない、または強電線と平行配線による電磁妨害（最も一般的で見つけにくい原因）。
• USB-CAN アダプターの電源異常。

妨害調査の重点：

電磁妨害による CAN 通信異常は、「断続的」かつ「ランダム」に現れることが多く、時には全て正常で、突然オフラインになり、電源再投入で復旧することがあります。調査時は以下に重点を置く：

• 配線レイアウト：CAN 通信線がモーター線、ヒーター線、ヒートベッド線とケーブルキャリア内で並列配線されていないか？高速 PWM 変調のモータードライバー信号とヒーターのスイッチングノイズは最強の妨害源です。
• シールド層の接地：シールド線使用時、シールド層は片端接地（ホスト側のみ）ですか？両端接地はグランドループを形成し、逆に妨害を引き起こします。
• 終端抵抗の位置：終端抵抗は CAN バスの物理的な末端に、ボード上のジャンパーピン、DIPスイッチ、または専用終端インターフェースを介して取り付けられていますか？
• CAN 線材仕様：ツイストペア線（撚りピッチが数cm以内）を使用していますか？平行線（ツイストペアでない）はコモンモード妨害に対する抑制能力がほとんどありません。
• 接地の完全性：マシンの電源、筐体は確実に接地されていますか？接地されていないマシンの金属フレームは大型アンテナとなり、環境ノイズを拾いやすくなります。

調査方法：

電源オフ操作

以下のハードウェア調査は、プリンターの電源を完全に切り、電源供給を切断した後に行う必要があります：CANH/CANL の確認、配線のやり直し、シールド層の調整、終端抵抗の有効化/無効化、CANH-CANL 抵抗の測定。

1. CAN バス上に 120Ω 終端抵抗が2つだけあることを確認。ボード上のジャンパーピン、DIPスイッチ、または専用終端インターフェースを使用することを推奨。
2. CANH/CANL の配線がしっかり固定されているか、コネクタが完全に差し込まれているか確認。
3. 先に電源を切ってから操作してください。マルチメーターで CANH-CANL 間の抵抗を測定（正常値は約 60Ω）。
4. 配線のやり直し：CAN 通信線を強電線から分離し、少なくとも 2-3cm の距離を保ち、平行配線を避ける。
5. シールド接地の確認：シールド線はホスト側のみ接地し、ツールボード側は浮かせたまま接続しない。電源を自分で分解したり、商用電源のアース線を変更しない。
6. candump を使用して CAN バスのトラフィックを監視し、大量のエラーフレーム（error frames）が発生していないか確認する。
7. 一時的に印刷速度/加速度を下げてテストし、問題が消失する場合、妨害がモータードライバーの強度と正の相関があることを示す。

ID が見つからない場合の調査順序

1. ip -details link show can0 を実行し、CAN0 が存在し、使用可能な状態であることを確認する。
2. ツールボード、メインボードのファームウェア CAN レートがホストの CAN0 レートと一致していることを確認する。
3. デバイス ID が既に printer.cfg に記述されている場合、一時的に対応する設定をコメントアウトし、約10秒間電源を切ってから再投入して検索する。
4. CAN-H と CAN-L が逆接続、断線、または接触不良でないか確認する。
5. CAN ネットワークの両端にそれぞれ 120Ω の終端抵抗があることを確認し、マシンの電源を切った状態で CAN-H と CAN-L 間の抵抗値を測定し、約 60Ω であることを確認する。
6. ツールボードまたはメインボードに正常に電源が供給されていることを確認する。
7. ファームウェアコンパイル時に正しい通信方式が選択されていることを確認する。
8. 検索結果に Application: CANBOOT または Application: Katapult と表示される場合、先に Klipper ファームウェアを書き込んでから再検索する。

終端抵抗のルール

電源オフ操作

終端抵抗のジャンパーピン、DIPスイッチの調整、または CAN ケーブルの抜き差しを行う前は、プリンターの電源を完全に切り、電源供給を切断してください。

デバイスタイプ	終端抵抗の要件	操作説明
CAN ツールボード	120Ω 終端抵抗が必要	ボード上のジャンパーピンまたは DIPスイッチで有効化
メインボード CAN インターフェース	120Ω 終端抵抗が必要	ボード上のジャンパーピンまたは DIPスイッチで有効化
UTOC タイプ変換モジュール	通常内蔵 120Ω 抵抗済み	追加で終端抵抗を有効にする必要なし

クイック調査順序

1. まずデバイスを確認：lsusb を実行し、1d50:606f が見えることを確認。
2. 次に設定を確認：ip -details link show can0 を実行し、CAN0 が存在し、レートが正しく、バッファが 1024 であることを確認。
3. 最後にハードウェアを確認：完全に電源を切って CAN-H と CAN-L 間の抵抗を測定し、約 60Ω であることを確認。

全て確認しても異常が続く場合、USB ケーブル、CAN ケーブル、UTOC、または CAN ブリッジデバイスを交換してクロステストを試みる。

CAN デバイスファームウェア更新リファレンス

このセクションは、既に CAN ネットワークに接続でき、CAN 経由でメインボードまたはツールボードのファームウェアを更新する必要がある場合のためのものです。製品ごとにファームウェア名やコンパイル方法が異なるため、まず該当製品のチュートリアルに従ってファームウェアをコンパイルしておいてください。

準備

1. 製品チュートリアルに従って新しいファームウェアをコンパイルする。
2. デバイスの CAN UUID が検索可能であるか、既に printer.cfg にそのデバイスの canbus_uuid: が記述されていることを確認する。
3. Klipper サービスを停止：

sudo systemctl stop klipper

更新の実行

以下のコマンドの <CAN_UUID> を実際のデバイス ID に置き換えてください。

バージョン説明

システムバージョンに応じて対応するコマンドを選択してください。

• FlyOS-FAST 1.3.8 以降 または 2026年4月9日以降に Klipper を更新したシステム：

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

• 旧バージョンシステム、つまり FlyOS-FAST 1.3.8 以前、または 2026年4月9日以前に Klipper を更新していないシステム：

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

注意

-u の後には必ずスペースを入れ、その後ろに CAN UUID を記述してください。

CAN Flash Success が表示されれば、通常は書き込み成功です。

Loading...

更新後の操作

更新が完了したら、Klipper を再起動します：

sudo systemctl start klipper

更新後に接続できない場合は、CAN ID を再検索し、printer.cfg 内の canbus_uuid: が正しいか確認してください。

最終確認リスト

CAN ID が見つからない、または Klipper が CAN デバイスに接続できない場合、以下の順序で素早く確認してください：

1. can0 がシステムに認識されている。
2. bitrate がファームウェアコンパイル時に設定した CAN レートと一致している。
3. qlen または txqueuelen が 1024 である。
4. CAN-H と CAN-L が逆接続されていない。
5. CAN バス両端の終端抵抗が正しい。
6. ツールボードまたはメインボードの電源供給が正常。
7. ファームウェアの通信方式が正しく選択されている。
8. printer.cfg で実際に検索された canbus_uuid: を使用している。
9. 同じ [mcu] 内で serial: と canbus_uuid: が同時に有効になっていない。