CAN エラー調査

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

適用シーン：

Klipper に CAN0、CAN UUID、または CAN ネットワーク関連のエラーが発生する場合。
CAN デバイスが断続的にオフラインになる、または見つからない場合。
CAN bytes_invalid、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` を上に遡り、最初の切断またはシャットダウンの根本原因を確認

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 バスメッセージが並べ替えられています。これは深刻な問題で、印刷プロセスのどの段階でも不安定性やランダムエラーを引き起こします。

既知の原因：

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

解決方法：

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

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

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

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

解決方法：

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

ip link show can0 | grep qlen

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

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

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

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

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

よくある原因：

CAN 終端抵抗が不足している、または正しくない（CANH-CANL 間には必ず 2 つの 120Ω 抵抗がなければなりません）。
CANH/CANL の配線が緩んでいる、圧着不良、またはコネクタが緩んでいる。
CAN 線がツイストペアシールド線を使用していない、または強電線と平行配線されていることによる電磁干渉（最も一般的で見えにくい原因）。
USB-CAN アダプタの電源供給異常。

干渉調査の重点：

電磁干渉による CAN 通信異常は、しばしば「断続的」かつ「ランダム」に現れます。つまり、正常な時もあれば、突然切断され、電源再投入で復旧することもあります。調査時は以下に重点を置く必要があります：

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

調査方法：

電源オフでの作業

以下のハードウェア調査は、プリンターの電源を完全に切り、電源を抜いた状態で行ってください：CANH/CANL の確認、配線のやり直し、シールド層の調整、終端抵抗の有効化/無効化、CANH-CANL 間の抵抗測定。

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

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

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

終端抵抗ルール

電源オフでの作業

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

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

クイック調査手順

まずデバイスを確認：lsusb を実行し、1d50:606f が表示されることを確認します。
次に設定を確認：ip -details link show can0 を実行し、CAN0 が存在し、レートが正しく、キャッシュが 1024 であることを確認します。
最後にハードウェアを確認：完全に電源を切った状態で CAN-H と CAN-L を測定し、抵抗値が約 60Ω であることを確認します。

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

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

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

準備

製品チュートリアルに従って新しいファームウェアをコンパイルします。
デバイスの CAN UUID を検索できること、または printer.cfg にそのデバイスの canbus_uuid: が記入されていることを確認します。
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 というメッセージが表示されれば、通常は書き込み成功です。

更新後の操作

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

sudo systemctl start klipper

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

最終チェックリスト

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

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

よくあるエラーの判断​

CAN 通信エラー調査​

CAN bytes_invalid カウンタが増加し続ける​

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

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

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

終端抵抗ルール​

クイック調査手順​

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

準備​

更新の実行​

更新後の操作​

最終チェックリスト​