メインコンテンツにスキップ

システム、パフォーマンス、サービスエラー

このページでは、ホーミング時の通信タイムアウト、MCUタイマーエラー、ホストPCのパフォーマンス、ファームウェア書き込み、Klipperサービスの起動に関する問題をまとめています。

ホーミングタイムアウト問題​

エラーメッセージ: ホーミング中に Communication timeout during homing、Error during homing xxx が発生します。複数のMCUを使用したZ軸ホーミングでよく見られます。

一般的な原因:

  • ホストPCの負荷が高すぎる。KlipperScreen、カメラストリームなどが同時に実行されている。
  • ホーミング時に複数の軸のモーターが同時に動き、大電流の駆動信号がCAN/USB通信線に結合し、通信が中断する。
  • 複数MCUの通信応答が不安定。
  • CAN/USB通信線の品質問題または配線方法の不適切さ。

解決方法:

電源オフ操作

CAN/USB配線の整理、シールド層の確認、接地の確認を行う前に、プリンターの電源を完全に切り、電源供給を切断してください。電源のアース線、商用電源の配線、電源内部の構造を独自に変更しないでください。

  1. まず電磁干渉を排除します。CAN/USB線がモーター線、ヒーター線から分離して配線されているか確認し、CANネットワーク構成とID検索 の干渉排查手順を参照してください。
  2. TRSYNC_TIMEOUT タイムアウトパラメータを調整するか、一時的にKlipperScreenを無効化してみてください。詳細は ホーミングタイムアウト問題 を参照。
  3. 機器の接地とシールド層の接地が正常か確認してください。

MCU 'mcu' shutdown: Stepper too far in past​

エラーメッセージ: KlipperがMCUに送信予定のステッパーイベントが現在時刻より遅れすぎており、MCUがこれらの動作コマンドを予定通りに実行できず、プリンターがシャットダウン状態になります。

Loading...

エラー原因: これは通常、特定の固定設定項目によるものではなく、ホスト側の動作計画、MCUのステッパー出力、または通信スケジューリングが処理に追いつかない結果発生します。ホストPCの負荷が高すぎる、印刷速度/加速度が高すぎる、ステッパー細分が高すぎる、複数MCUの通信遅延、USB/CAN通信品質の低下、マクロやGコードが短時間に大量の動作コマンドを生成する、などがこの問題を引き起こす可能性があります。

参考シナリオ: 多点プローブ（メッシュベッド）実行時、[bed_mesh] の probe_count 設定が大きすぎ、かつ高い mesh_pps が同時に設定されている場合、過密なグリッドデータが生成され、ホストPCの計算と動作計画の負荷が増加する可能性があります。これはよくあるシナリオの一つに過ぎません。メッシュベッドがなくても、システム負荷や通信遅延が増加する他の状況でも Stepper too far in past が発生する可能性があります。

復旧後の印刷停滞シナリオ: このエラーは PAUSE / RESUME、フィラメント切れ検知からの復帰、停電復旧後の印刷再開後にも発生する可能性があります。典型的なログの挙動は以下の通りです。復帰後、Stats 行の buffer_time が約 1s から 0.2s 前後に急降下し、sd_pos がほぼ増加しなくなる（印刷進行が停滞する）一方、sysload は高くなく、MCUの接続断もありません。これは、復帰後に動作コマンドがステッパーバッファを継続的に満たせず、プリンターが「開始しているがほとんど動いていない」状態でシャットダウンすることを示しています。調査時は、復帰/再開マクロ（resume_gcode、start_gcode）が復帰直後に異常な大きな移動やリトラクトコマンドを送信していないか、また復帰前に通信再送（bytes_retransmit の増加）が既に発生していないかを重点的に確認してください。

解決方法:

  1. まず klippy.log のエラー発生前の Stats 行を確認し、CPU使用率の高さ、bytes_retransmit、bytes_invalid、Timer too close、MCUの接続断、またはキュー異常が同時に存在するか確認します。
  2. カメラストリーム、KlipperScreen、リモートコントロールプラグイン、その他の高負荷サービスを一時的に無効化し、ホストPCの負荷を下げて再テストします。
  3. 印刷速度、加速度、ステッパー細分を下げて、エラーが消えるか観察します。
  4. エラーが多点プローブ（メッシュベッド）中に発生する場合、[bed_mesh] の probe_count を減らします。例: 7,7 や 9,9 に変更してテスト。
  5. 高い mesh_pps が設定されている場合、その設定値を下げるか削除します。例: mesh_pps: 2,2 に変更。
  6. USB/CAN通信品質を確認します。CANを使用している場合、キューの長さ、終端抵抗、配線順序、電源供給、ファームウェアのCANレートを確認します。
  7. エラー発生前に実行中のマクロやGコードを確認し、マクロのループ、過密な短い線分、異常なスクリプトが短時間に大量の動作コマンドを送信しないようにします。

関連設定の参考: マクロ紹介、一般的なデバッグコマンド。

MCU 'mcu' shutdown: Timer too close​

エラーメッセージ: MCUタイマーが近すぎるため、システムがタイムアウトします。

Loading...

エラー原因: 下位機（MCU）の処理負荷が高すぎる、ホストPCの応答タイムアウト、印刷速度が高すぎる、細分が高すぎる、システム時刻同期の干渉、またはMCU通信線への干渉がこの問題を引き起こす可能性があります。

最近の一般的なシナリオ:

  • M600、PAUSE、RESUME、フィラメント切れ検知、またはフィラメント交換マクロが一定時間待機した後に印刷を再開し、その後 Timer too close が発生する。
  • EDDY / TAP / CANツールボードがZホーミング、Z_TILT_ADJUST、QUAD_GANTRY_LEVEL、またはメッシュベッドに参加している際、ログにCAN再送、I2C読み取り異常、またはホストPCの負荷スパイクが同時に発生する。
  • マルチツールヘッド、複数のCANノード、または低性能のホストPCでカメラ、KlipperScreen、リモートコントロールプラグインを同時に実行している場合、スケジューリングの余裕が不足する。

解決方法:

  1. ステッパーモーターの細分を下げ、MCUのパルス処理負荷を減らします。
  2. 印刷速度と加速度を下げ、問題が消えるか観察します。
  3. ホストPCの負荷、電源供給、USB/CAN通信品質を確認します。
  4. 電源を切った後、MCUとホストPC間の通信線がモーター線、ヒーター線、ヒートベッド線、電源線に近接していないか確認し、必要に応じて再配線するか、シールド付き通信線に交換します。
  5. 機器の接地状態を確認する際は、メーカーが提供する接地ポイントとコンセントの状態のみを確認し、電源を独自に分解したり、商用電源のアース線を変更したりしないでください。
  6. 問題がホーミング段階で発生する場合、ホーミングタイムアウト問題 を参照してください。
  7. M600 またはフィラメント切れ検知からの復帰後に発生する場合、マクロ内で PAUSE が繰り返されていないか、フィラメント切れセンサーがフィラメント交換中に誤動作していないか、SAVE_GCODE_STATE / RESTORE_GCODE_STATE の名前が一致しているかを確認します。
  8. EDDY TAP、Zチルト、またはガントリーレベリング中に発生する場合、まず EDDY TAP モードデバッグ方法 を参照するか、EDDY 問題集 に従って排查します。
  9. 問題が続く場合は、ホストPCのシステムまたはファームウェアの再書き込みを検討します。

関連設定の参考: 一般的なデバッグコマンド、ホーミングと方向校正ガイド。

MCU shutdown: Missed scheduling of next digital out event​

エラーメッセージ: MCU 'xxx' shutdown: Missed scheduling of next digital out event。

エラー原因: Klipperホスト側がヒーター、ファンなどのデジタル出力をオンにした後、MCUはその後のスケジューリングと確認を時間通りに受け取る必要があります。ホストPCの負荷が高すぎる、システムスケジューリングの遅延、USB/CAN通信の不安定さ、またはCANバスキューの異常がある場合、MCUが次のデジタル出力イベントを時間通りに受け取れず、シャットダウン状態になります。

注意

このエラーはヒーター出力のスケジューリングに関連しています。温度保護の無効化、verify_heater の無効化、安全設定の削除によってエラーを回避しないでください。まずホストPCの負荷と通信品質を排查してください。

解決方法:

  1. まず klippy.log のこのエラー発生前の Stats 行を確認し、bytes_retransmit、bytes_invalid、Timer too close、またはMCUの接続断の記録が同時に存在するか確認します。
  2. ホストPCの負荷を下げ、カメラストリーム、KlipperScreen、リモートコントロールプラグイン、その他の高負荷サービスを一時的に無効化します。
  3. USB/CAN通信品質を確認します。CANを使用している場合、CAN0キューの長さ、終端抵抗、配線順序、電源供給、ファームウェアのCANレートを確認します。
  4. 印刷速度、加速度、ステッパー細分を下げ、問題が消えるか観察します。
  5. 加熱時のみ発生する場合、ヒートベッド、ホットエンド、ファン、電源負荷を同時に確認します。電源を独自に分解したり、商用電源のヒートベッド高圧配線を確認したりしないでください。
  6. 問題がCANツールボードで発生する場合、CANエラー排查 に従って処理を続行します。

関連設定の参考: 一般的なデバッグコマンド、CANネットワークとID検索。

Rescheduled timer in the past​

エラーメッセージ: ログに Rescheduled timer in the past または類似の警告が表示されます。

エラー原因: ホストPCのシステムクロック問題またはCPU負荷が高すぎるため、タイマー処理の実際の実行時刻が予定時刻より遅れます。

解決方法:

  1. NTP同期が有効になっている場合、一時的に無効化してテストします。
  2. 不要なWebインターフェース、カメラストリームなど、ホストPC上で実行されている他のサービスの負荷を下げます。
  3. 仮想マシンで実行している場合、物理マシンへの移行、またはより安定したクロックソースの使用を検討してください。
  4. ホストPCのCPU使用率を確認します: htop で klippy プロセスに異常なCPU使用率がないか確認します。 関連設定の参考：常用デバッグ指令。

MCU 'mcu' shutdown: Move queue overflow​

エラーメッセージ: MCU 'mcu' shutdown: Move queue overflow。

エラーの原因: MCUのモーションキューが満杯になり、ホスト側が運動計画と状態をMCUにタイムリーに同期できていない。一般的には、ホストの性能不足、短時間に大量の細かい移動、KlipperホストとMCUファームウェアのバージョン不一致、またはベンダーがカスタマイズしたKlipperが各移動コマンドに同期書き込みや停電再開などのブロッキング処理を追加している場合に発生する。

一般的な判断ポイント:

  • klippy.log内でGit versionとLoaded MCU 'xxx' ... versionの基本バージョン差が大きい。
  • ログにdirty、サードパーティ製のklippy/extrasファイル、ベンダーカスタマイズの停電再開、または非公式Klipperが表示される。
  • 同じG-codeファイルが同じような位置で失敗し、モデルに多数の短い線分、密集したサポート、スパイラルZホップ、または複雑なパスが含まれている。
  • 低性能の上位機が同時にカメラ、画面、リモートコントロール、その他の高負荷サービスを実行している。

解決方法:

  1. 完全なklippy.logを確認し、より早いTimer too close、CAN切断、bytes_invalid、温度/TMCエラーがないか先に確認する。
  2. Klipperを更新した後、すべてのMCUファームウェアを再コンパイルして書き込み、上位機とマザーボード、ツールボードのファームウェアバージョンを一致させる。
  3. 一時的にカメラストリーム、KlipperScreen、リモートコントロールプラグイン、その他の高負荷サービスを無効にして再テストする。
  4. 印刷速度、加速度、マイクロステッピングを下げるか、スライサーで曲線精度、サポートの複雑さ、短線分密度を下げる。
  5. ベンダーカスタマイズの停電再開、自動高さ記録、またはサードパーティプラグインを使用している場合は、まずオリジナルのKlipperを使用するか、関連機能を無効にしてクロステストする。一般顧客向けの通常手順としてKlipperソースコードを直接変更しない。
  6. 特定のG-codeファイルでのみ発生する場合は、再スライスし、スライサーが異常に密集したパスを出力していないか確認する。

関連設定の参考：常用デバッグ指令、円弧フィッティングの提案。

stepcompress / syncemitter / flush_handler 内部エラー​

エラーメッセージ: stepper.error: Internal error in stepcompress、stepcompress ... Invalid sequence、Error in syncemitter 'extruder' step generation、Exception in flush_handler、Flush Handler error。

エラーの原因: Klipperがステッピングパルスの生成または圧縮中に内部例外が発生した。最近のコミュニティ事例では、この種の問題は高速ベッドメッシュ計測、scanner / EDDY / Cartographer タイプのプローブプラグイン、input_shaper、複雑な移動パス、またはサードパーティ製Klipperの変更と同時に発生することが多い。これは必ずしもスライサー単独の原因ではなく、再スライスだけで根本原因を判断すべきではない。

解決方法:

  1. 完全なklippy.logを保持し、そのエラーの前後のPython Traceback、実行中のコマンド、Stats行に注目する。
  2. エラーがBED_MESH_CALIBRATE、QUAD_GANTRY_LEVEL、またはscannerでのベッドメッシュ計測中に発生する場合は、まず計測速度、点数、補間密度、プラグインのスキャンパラメータを下げる。
  3. サードパーティ製のscanner、自動速度調整、自動レベリング拡張、マクロパック、またはベンダーによる変更を一時的に無効にし、オリジナルのKlipperで再テストする。
  4. Klipperを更新した後、すべてのMCUファームウェアを再書き込みし、周辺機器ファームウェアとホストのKlipperバージョンが一致していることを確認する。
  5. 同じモデルで繰り返し発生する場合は、再スライスして短線分密度を下げる。再スライス後もランダムに発生する場合は、ホスト負荷、運動パラメータ、プラグインの互換性を引き続き調査する。
  6. プリンタが異常な動き、脱調、または衝突のリスクがある場合は、直ちに緊急停止して再ホーミングし、元のタスクを続行しない。

関連設定の参考：運動、リミット、レベリングエラー、EDDY問題まとめ。

Internal error during connect / has no attribute​

エラーメッセージ: Klipperを更新した後、起動が完了できず、ログにUnhandled exception during connect、Internal error during connectが表示される。Tracebackの末尾は次のようになる場合がある：

AttributeError: 'MCU' object has no attribute '_serialport'

その他のhas no attribute、got an unexpected keyword argument、またはモジュールインターフェース欠落のヒントが表示される場合もある。

エラーの性質: この種のエラーは、Klipperが接続初期化段階でPythonコードを実行中に例外が発生したことを示す。最近のコミュニティ事例では、Tracebackがサードパーティ製のklippy/extras/モジュールを指している場合、通常はKlipperが内部インターフェースを更新したが、旧バージョンの拡張機能やベンダーカスタマイズモジュールがまだ元のインターフェースを呼び出していることが原因である。これは一般的にMCUファームウェアの破損ではなく、シリアルポートケーブル障害として先に処理すべきではない。

一般的な原因:

  • Klipperは更新されたが、サードパーティ製のプローブ、フィラメント交換、マクロパック、その他の拡張機能が同期して更新されていない。
  • ベンダーカスタマイズのKlipperブランチを使用しているが、オリジナルのKlipperにのみ適合する拡張機能を混用している。
  • 拡張機能の更新時にファイルが不完全で、新旧のPythonファイルが同時に残っている。
  • Tracebackが実際には設定ファイル、変数ファイル、またはオリジナルモジュール内の他の例外を指しており、拡張機能の互換性問題ではない。

解決方法:

  1. 完全なklippy.logを保存し、最初のUnhandled exception during connectからTracebackを下方向に読み、最後の例外と、その例外の直前にある最後のklippy/extras/xxx.pyファイル名を記録する。
  2. ログ冒頭のGit version、Modified files、Untracked filesを確認する。例外ファイルがサードパーティ製の拡張機能に属する場合は、まずその拡張機能のメンテナンス説明に従って現在のKlipperに適合するバージョンに更新する。
  3. Tracebackが指すサードパーティモジュールまたは関連するincludeを一時的に無効にして再起動し、オリジナルのKlipperが正常に接続できるか確認する。Python属性の欠落に対してMCUの再書き込みを繰り返してはならない。
  4. ベンダーカスタマイズのKlipperを使用している場合は、そのシステムが明示的にサポートする更新方法を使用する。オリジナルのKlipper、カスタムブランチ、異なるバージョンの拡張機能を勝手に混在させない。
  5. TracebackがオリジナルのKlipperファイルのみを指し、Modified files / Untracked filesがすべて正常な場合は、現在の安定版に更新して再度完全なログを収集し、Klipperコミュニティに再現手順を報告する。
  6. ダウングレードはバージョン互換性の問題かどうかを確認するための短期的な手段としてのみ使用する。長期的な解決策は拡張機能を更新するか、互換性のないモジュールを削除することであり、既知の古すぎるバージョンに長期間留まるべきではない。

Internal error during ready callback: Unable to save variable​

エラーメッセージ: Klipper起動後すぐにshutdownに入り、ログに次のキーワードが表示される：

Unable to save variable
reactor.ReactorError: Internal error - reactor pause disabled
Unhandled exception during ready callback
Internal error during ready callback: Unable to save variable

エラーの性質: Unable to save variableは変数の書き込み失敗の結果を示すに過ぎない。最近のコミュニティ事例では、これがreactor pause disabled、ready callbackと同時に発生する場合、通常はサードパーティ製の拡張機能がKlipperのreadyコールバック段階でSAVE_VARIABLEを呼び出しており、新しいバージョンの非同期書き込みメカニズムと互換性がないことを示す。これはストレージデバイスの破損やMCUの切断と同等ではない。

一般的な原因:

  • Klipperを更新した後、旧バージョンのサードパーティ製拡張機能が起動コールバックで変数を同期書き込みしている。
  • 拡張機能またはベンダーカスタマイズモジュールが同期して更新されておらず、Tracebackがそのklippy/extras/ファイルを指している。
  • ログにreactor pause disabledがない場合、変数ファイルのパスエラー、ディレクトリの読み取り専用、ディスク容量不足、または権限異常の可能性もある。

解決方法:

  1. klippy.log内の最初のUnable to save variableから完全なPython Tracebackを読み、最初に表示されるサードパーティモジュールのパスと例外の原文を記録する。最後のshutdown行だけを見ない。
  2. reactor pause disabledとサードパーティ製の拡張機能パスが同時に表示される場合は、まずその拡張機能を現在のKlipperに適合するバージョンに更新してからKlipperを再起動する。互換性のあるバージョンがない場合は、拡張機能のメンテナに連絡する。
  3. Tracebackが指すサードパーティ製の拡張機能または関連するincludeを一時的に無効にして再テストし、オリジナルのKlipperが正常に起動できるか確認する。通常の調査手順としてKlipperのコアソースコードを直接変更しない。
  4. TracebackがPermission denied、Read-only file system、またはNo space left on deviceを示す場合は、次のコマンドを実行してディスク容量と変数ファイルの権限を確認し、実際のパスまたは権限を修正する。無関係なディレクトリの権限を広げるためにchmod 777を使用しない。
df -h
ls -l ~/printer_data/config/
  1. Klipperのダウングレードは短時間の互換性検証のみに使用し、長期的な解決策とすべきではありません。問題を確認した後は、サポートされているKlipperバージョンに復元し、対応する拡張機能を更新してください。

コマンド実行時の内部エラー​

エラーメッセージ: Internal error on command:"XXX"、Klipperがシャットダウン状態になります。

一般的な原因:

  • マクロまたはGコードコマンドがKlipper内部のPython例外をトリガーした。
  • 設定ファイルに誤ったマクロ参照またはJinja2テンプレートの構文エラーが存在する。
  • Klipperのバージョンと設定ファイルの形式が互換性がない。
  • Gコードファイル名に特殊文字が含まれ、エンコードエラーが発生した。
  • stepcompress、syncemitter、またはflush_handlerがエラーを報告し、コマンド実行が中断された。

解決方法:

  1. klippy.logのInternal errorの下にある完全なPython Tracebackを確認します。
  2. Tracebackに基づいて、どの設定ファイルまたはマクロに問題があるかを特定します。
  3. 一般的な原因には、[gcode_macro]内のJinja2テンプレート構文エラー、[respond]設定の欠落、[virtual_sdcard]パスの誤りが含まれます。
  4. エラーがSDCARD_PRINT_FILEに関連し、ascii codec can't decodeと表示される場合は、Gコードファイル名を英数字、アンダースコア、またはハイフンに変更してください。
  5. Tracebackにstepcompress、syncemitter、またはflush_handlerが表示される場合は、stepcompress / syncemitter / flush_handler 内部エラーに従って調査を続けてください。

関連設定の参照：マクロ紹介、設定変更の説明。

ファイルを開けない / SDビジー​

エラーメッセージ: ファイル印刷時にUnable to open file、Unable to get file list、SD busy、SD write not supported、SDCARD_RESET_FILE cannot be run from the sdcardと表示される。

一般的な原因:

  • Gコードファイルが存在しない、ファイル名が変更された、またはアップロードが完了していない。
  • [virtual_sdcard] pathが誤ったディレクトリを指している。
  • ファイルの権限が異常で、Klipperユーザーが読み取れない。
  • ファイル名に特殊文字が含まれ、一部のフロントエンドまたはシステムのパス処理が異常になる。
  • 印刷中またはファイル読み取り中に、仮想SDのオープン、選択、リセット、または書き込みコマンドを再度実行した。
  • Klipperソースコードディレクトリ、設定ディレクトリ、またはその他のGコード以外のディレクトリを誤って[virtual_sdcard] pathに設定した。

解決方法:

  1. ウェブインターフェースでGコードファイルを再アップロードし、ファイル名が印刷コマンドと一致することを確認します。
  2. [virtual_sdcard] pathが実際のGコード格納ディレクトリを指しているか確認します。
  3. ディレクトリの権限を確認します：ls -la ~/printer_data/gcodes/。
  4. ファイル名を英数字、アンダースコア、またはハイフンに変更してから再テストします。
  5. SD busyと表示される場合は、先に現在の印刷を一時停止またはキャンセルし、他のマクロが仮想SDファイルを操作していないことを確認します。
  6. ~/klipper、~/printer_data/config、またはシステムディレクトリをGコード格納ディレクトリに設定しないでください。

関連設定の参照：設定変更の説明。

MCU CRCが設定と一致しない / MCU設定を更新できない​

エラーメッセージ: MCU 'xxx' CRC does not match config、Can not update MCU 'xxx' config as it is shutdown、Unable to configure MCU 'xxx'。

判断のポイント: Can not update MCU 'xxx' config as it is shutdownは通常、最初の根本原因ではなく、MCUがすでにシャットダウン/エラー状態になった後、KlipperがMCUに再接続または再設定する際に発生する後続のエラーです。調査時はログの最後の行だけを見ず、より早い時点の最初の実際のエラーを遡って確認してください。

解決方法:

  1. FIRMWARE_RESTARTを実行し、必要に応じて機器全体の電源を10秒間オフにしてから再度オンにします。
  2. klippy.logでより早い時点の最初のshutdown、Timer too close、Lost communication、Verify heater、TMCまたは温度エラーを確認し、まずシャットダウンの根本原因を修正します。
  3. 複数MCUのマシンでは、[mcu]、[mcu xxx]のUSB IDまたはCAN UUIDを個別に確認します。
  4. Klipperを更新したばかりの場合は、すべてのMCUファームウェアを再コンパイルして書き込んでください。
  5. [mcu host]を使用している場合は、klipper-mcuサービスが正常に起動しているか確認し、Klipperを再起動します。
  6. プリインストールまたはカスタムKlipperシステムを使用している場合は、ログが完全であり、KlipperとMCUファームウェアのバージョンソースが一致していることを確認します。

MCU 'xxx' shutdown: Command request​

エラーメッセージ: MCU 'xxx' shutdown: Command request。

一般的な原因:

  • CANツールボードのファームウェアバージョンとホストPCのKlipperバージョンが一致せず、ホストPCがそのファームウェアでサポートされていないコマンドを送信した。
  • Klipperまたはシステムを更新した後、ツールボードのファームウェアを再コンパイルして書き込んでいない。
  • そのMCUファームウェアでコンパイルサポートされていない機能を設定した（I2Cを有効にしていないのにEDDY / ADXLを設定したなど）。

解決方法:

  1. klippy.logのLoaded MCU 'xxx' ... versionとGit versionを確認し、バージョンが一致しているか確認します。
  2. エラーを報告したMCUのファームウェアを再コンパイルして書き込みます。書き込み方法は対応するツールボードの製品ドキュメントに従ってください。
  3. 複数MCUのマシンでは、すべてのMCUファームウェアが同じコンパイルによるものであることを確認します。
  4. 書き込み完了後、FIRMWARE_RESTARTを実行し、エラーが再発しないことを確認します。

一般的なバージョン調査: MCU Protocol error

M112コマンド / webhooksリクエストによるシャットダウン​

エラーメッセージ: Shutdown due to M112 commandまたはShutdown due to webhooks request。

解決方法:

  1. 人為的に緊急停止をクリックしたか確認します。その場合、リスクを排除した後、FIRMWARE_RESTARTを実行します。
  2. カスタムマクロでM112、action_emergency_stop、emergency_stopを検索します。
  3. フロントエンド、リモートコントロールプラグイン、または自動化スクリプトが誤って緊急停止インターフェースをトリガーしていないか確認します。

ホストPCの性能不足による印刷のカクつき​

エラーメッセージ: 明確なエラーはないが、印刷中に断続的な停止、押し出しの断続が発生する。

解決方法:

  1. 印刷速度と加速度を下げます。
  2. ホストPC上の不要なWebサービス、カメラストリームなどを停止します。
  3. [bed_mesh]のprobe_countとmesh_ppsを減らします。
  4. スライサーがG2 / G3円弧を出力する場合は、円弧フィッティングの提案を参照して調整または無効にします。
  5. ホストPCの性能が本当に不足している場合は、より高性能なホストPCへの交換を検討します。

ホストPCの異常再起動 / システムクラッシュ​

エラーメッセージ: 印刷中にKlipper / Moonrakerが突然切断され、klippy.logが突然中断し、明確なシャットダウンの根本原因がない。Mainsail / Fluiddが再接続すると、ホストPCまたはKlipperが再起動されたことがわかる。

一般的な原因:

  • ホストPCへの電力供給が不足しており、印刷中のUSB、カメラ、画面、ファンの負荷変化により電源が落ちる。
  • システムディスク、TFカード、またはeMMCの読み書き異常により、ログが突然中断したりファイルが破損したりする。
  • ホストPCのCPUが過熱し、システムが保護的に周波数を下げ、フリーズまたは再起動する。
  • USB逆給電または周辺機器の給電経路の異常により、マザーボード、画面、ホストPCが相互に影響を与える。
  • サードパーティサービス、カメラストリーム、AIプラグイン、または過剰なWeb接続がリソースを消費する。

調査方法:

電源オフ操作

ホストPCの電源ケーブル、USBケーブル、画面ケーブル、ファンケーブルを確認したり配線を整理したりする前に、プリンターの電源を完全にオフにし、電源供給を切断してください。電源を分解したり、市電の配線を変更したりしないでください。

  1. まずklippy.log、moonraker.log、およびシステムログを確認し、KlipperのエラーなのかホストPC全体の再起動なのかを確認します。
  2. ホストPCの電源仕様を確認し、電流不足や電圧降下が顕著な電源ケーブルを避けます。
  3. システムディスクの健全性を確認し、必要に応じて信頼性の高いTFカード、eMMCに交換するか、システムを再書き込みします。
  4. ホストPCの冷却を確認し、ファンが正常に動作し、ヒートシンクが密着し、ケースの通気が確保されていることを確認します。
  5. 一時的にカメラストリーム、KlipperScreen、リモートコントロールプラグイン、その他の高負荷サービスを無効にしてから印刷テストします。
  6. USB逆給電が疑われる場合は、完成品のUSBケーブルまたは電源絶縁のある接続方法を優先して使用し、一般ユーザーは自分で配線を変更しないでください。

一時停止、再開、状態保存に関する通知​

エラーメッセージ: Print already paused、Print is not paused, resume aborted、Unknown g-code state: PAUSE_STATE。

一般的な原因:

  • PAUSEを繰り返し実行した、または印刷がすでにキャンセルされた後にRESUMEを実行した。
  • カスタム一時停止/再開マクロでSAVE_GCODE_STATE NAME=とRESTORE_GCODE_STATE NAME=の名前が一致しない。
  • サードパーティのマクロパッケージとMainsail / Fluiddのデフォルトの一時停止/再開マクロが重複定義またはロジック競合を起こしている。
  • 緊急停止、FIRMWARE_RESTART、またはKlipperエラー後、元の一時停止状態が失われた。 解決方法：
  1. 現在のプリント状態を確認し、一時停止していないのに RESUME を実行しないこと。
  2. [pause_resume] が有効かどうか、また PAUSE / RESUME / CANCEL_PRINT マクロが重複定義されていないかを確認する。
  3. マクロ内の SAVE_GCODE_STATE と RESTORE_GCODE_STATE の名前が完全に一致しているかを確認する。
  4. Klipper がエラーを報告した後、または緊急停止後のプリント再開は推奨しない。リスクを排除した上で再開すること。

Klipper が繰り返し再起動する（Klippy not connected が繰り返し点滅）​

エラーメッセージ：Mainsail / Fluidd に Klippy not connected が繰り返し表示され、Klipper が自動再起動を繰り返し、毎回数秒以内に終了する。ログには Klipper restarting too fast が表示されたり、再起動のたびに klippy.log が非常に短い場合がある。

調査方法：

  1. まずログファイルの末尾を確認し、最後の終了理由を特定する：

    tail -100 ~/printer_data/logs/klippy.log

  2. ログ末尾が Python Traceback の場合、設定解析または内部例外によるクラッシュを示す。

  3. Klipper restarting too fast だけで根本原因を判断しないこと。これは通常、systemd が起動を繰り返し失敗した結果に過ぎないため、klippy.log 内の最初の実際のエラーを優先的に処理すること。

  4. ログ末尾に MCU Protocol error、Unknown command などが表示される場合、ファームウェアのバージョン不一致を示すため、MCU ファームウェアを再コンパイルして書き込む必要がある。

  5. ログが非常に短く明確なエラーがない場合、最小構成での二分法を用いて切り分けを試みる。

  6. include ファイルに循環参照がないかを確認する。

Unhandled exception during run​

エラーメッセージ：Unhandled exception during run が表示され、フロントエンドに Printer is shutdown と表示され、ログには Python Traceback が伴う。

よくある原因：

  • これは独立したハードウェア障害ではなく、Klipper のメインループが未処理の例外を捕捉したときの汎用エラーである。実際の原因は Traceback の上にある具体的なエラーを確認する必要がある。
  • よくあるトリガー源：TMC UART 読み取り失敗（Unable to read tmc uart 'stepper_x' register DRV_STATUS）、CAN 通信断絶、マクロテンプレート実行時エラー、サードパーティ拡張モジュールの異常。
  • Klipper アップグレード後、旧設定や旧マクロが新しいバージョンの API と互換性がない。
  • 上位機の Python 環境が破損している、または依存関係が欠落している。

解決方法：

  1. 完全な klippy.log を開き、Unhandled exception during run の上にある Traceback を検索し、最初の実際のエラーを見つける（例：Unable to read tmc uart、CanError、TypeError など）。
  2. 実際のエラーが TMC UART 通信失敗の場合、TMC エラー調査 に従って配線と設定を確認する。
  3. CAN 通信異常の場合、CAN エラー調査 に従ってバス状態を確認する。
  4. Traceback が特定のマクロや拡張モジュールを指している場合、そのモジュールが現在の Klipper バージョンと互換性があるかを確認し、必要に応じて更新または一時的に無効化する。
  5. Klipper アップグレード後にこのエラーが発生した場合、Config_Changes.md に設定移行の要件がないか確認する。
  6. Unhandled exception during run という行だけで問題を判断しないこと。これは単なる外殻であり、真の原因は常に Traceback 内にある。

Missed scheduling of next hard pwm event​

エラーメッセージ：MCU 'mcu' shutdown: Missed scheduling of next hard pwm event。

よくある原因：

  • Missed scheduling of next digital out event と同種で、上位機が期限までに PWM イベントを MCU に送信できなかったことを示す。
  • 上位機の CPU 負荷が高い（カメラストリーム、KlipperScreen、多数のプラグインの同時実行）。
  • レーザーモジュールや高周波 PWM ツールを使用する際、cycle_time が小さすぎてスケジュール間隔が極端に短くなっている。
  • CAN バスの遅延が高く、イベントが転送中にタイムアウトする。

解決方法：

  1. 上位機の CPU 負荷を確認し、カメラ、KlipperScreen、その他の不要なサービスを一時的に停止して再テストする。
  2. レーザーや PWM ツールを使用している場合、cycle_time を適切に増やす（例：0.00002 から 0.0001 に変更）。
  3. CAN バスの状態を確認し、tx_error、bytes_retransmit が継続的に増加していないことを確認する。
  4. 高品質の USB ケーブルに交換するか、CAN ボーレートを下げて（1M から 500K へ）テストする。
  5. 低性能の上位機（古いスマホ、低性能開発ボード）では、同時に実行するサービスの数を減らすことを推奨する。

関連エラー：Missed scheduling of next digital out event

Can't reset time when stepper active​

エラーメッセージ：MCU 'mcu' shutdown: Can't reset time when stepper active。プリント途中の Klipper 自動再起動を伴うことが多い。再起動後に TMC stepper_x failed to init: Timeout on wait for 'tmcuart_response' response が続いて発生する場合がある。

よくある原因：

  • これは独立したハードウェア障害ではなく、上位機がステッピングモーターがまだ動作中にステッパークロック基準のリセットを試み、MCU が拒否してシャットダウン保護に入ったことを示す。
  • 最も一般的なトリガー源は、プリント途中の Klipper サービスの自発的な再起動（上位機側）：ログに、直前までプリント統計行が記録されていた直後に Starting Klippy... が表示される。
  • Moonraker に接続されたクライアントまたはプラグインがサービス再起動を繰り返し要求している。
  • 上位機の電力不足、過熱、メモリ枯渇などにより、システムが klipper サービスを強制終了した後に再起動している。

解決方法：

  1. 完全な klippy.log を開き、Starting Klippy... を検索し、Klipper がプリント途中で再起動したかどうか、および直前のプリント統計行との時間間隔を確認する。
  2. systemctl status klipper.service と journalctl -efu klipper を実行し、サービス再起動の記録と理由を確認する。
  3. Moonraker に接続されたクライアントとプラグイン（カメラストリーム、サードパーティプラグイン、カスタムスクリプト）を確認し、サービス再起動やマシン再起動を要求するデバイスがないことを確認する。
  4. 上位機の電力供給、冷却、メモリ使用量を確認する。古い Raspberry Pi や低性能開発ボードでカメラと KlipperScreen を同時に実行すると、メモリ不足でシステムに強制終了されることがある。
  5. 再起動後に発生する Timeout on wait for 'tmcuart_response' は再起動の結果であり根本原因ではないため、先に TMC 配線を調査しないこと。

関連エラー：Klipper が繰り返し再起動する、Unhandled exception during run

Loading...