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

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

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

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

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

一般的な原因：

  • 上位機の負荷が高く、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 のステッパー出力、または通信スケジューリングが処理に追いつかないことが原因です。上位機の負荷が高い、プリント速度/加速度が高すぎる、ステッパーミクロンステップが高すぎる、複数 MCU 間の通信遅延、USB/CAN 通信品質の低下、マクロや G コードが短時間に大量の動作命令を生成するなど、さまざまな要因がこの問題を引き起こす可能性があります。

参考シナリオ：多点ベッドメッシュを実行する際、[bed_mesh] の probe_count が大きすぎ、かつ高い mesh_pps が設定されている場合、過密なメッシュデータが生成され、上位機の計算と動作計画の負荷が増大する可能性があります。これはよくあるシナリオの一例です。ベッドメッシュがなくても、システム負荷や通信遅延が高まる他の状況でも 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、リモートコントロールプラグイン、その他負荷の高いサービスを一時的に無効にし、上位機の負荷を下げて再テストします。
  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 通信線への干渉などが原因で発生する可能性があります。

最近よく見られるシナリオ：

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

解決方法：

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

関連設定の参考：よく使うデバッグコマンド、ホーミングと方向調整ガイド。

MCU shutdown: Missed scheduling of next digital out event​

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

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

注意

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

解決方法：

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

関連設定の参考：よく使うデバッグコマンド、CAN ネットワークと ID 検索。

Rescheduled timer in the past​

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

エラーの原因：上位機のシステムクロックの問題、または CPU 負荷が高く、タイマータスクの実際の実行時間が計画時間より遅れています。

解決方法：

  1. NTP 同期が有効になっている場合は、一時的に無効にしてテストします。
  2. 不要な Web インターフェースやカメラストリームなど、上位機で動作している他のサービスの負荷を下げます。
  3. 仮想マシンで実行している場合は、物理マシンへの移行や、より安定したクロックソースの使用を検討します。
  4. 上位機の 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-hop、または複雑なパスが含まれている。
  • 低性能の上位機（シングルボードコンピュータなど）で、カメラ、画面、リモート制御、またはその他の高負荷サービスが同時に実行されている。

解決方法：

  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、またはスキャナーのプロービング中に発生した場合、まずプロービング速度、ポイント数、補間密度、プラグインのスキャンパラメータを低減する。
  3. サードパーティのスキャナー、自動速度調整、自動レベリング強化、マクロパッケージ、またはメーカーの修正を一時的に無効にし、オリジナルのKlipperで再テストする。
  4. Klipperを更新後、すべてのMCUファームウェアを再書き込みし、周辺機器ファームウェアがホストのKlipperバージョンと一致していることを確認する。
  5. 同じモデルで繰り返し発生する場合、再スライスして短線分密度を低減する。再スライス後もランダムに発生する場合は、ホスト負荷、動作パラメータ、プラグインの互換性を引き続き調査する。
  6. プリンターに異常な動作、脱調、衝突のリスクがある場合は、すぐに緊急停止して再ホーミングし、元のタスクを再開しないこと。

関連設定参考：動作、リミット、レベリングエラー、EDDY問題集。

Internal error on command​

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

よくある原因：

  • マクロまたはG-codeコマンドがKlipper内部のPython例外をトリガーした。
  • 設定ファイルに誤ったマクロ参照やJinja2テンプレートの構文エラーが存在する。
  • Klipperのバージョンと設定ファイルの形式に互換性がない。
  • G-codeファイル名に特殊文字が含まれており、エンコーディングエラーが発生した。
  • 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-codeファイル名を英数字、アンダースコア、またはハイフンのみに変更する。
  5. Tracebackにstepcompress、syncemitter、またはflush_handlerが含まれる場合は、stepcompress / syncemitter / flush_handler 内部エラーに従って引き続き調査する。

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

Unable to open file / SD busy​

エラーメッセージ：ファイル印刷時に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-codeファイルが存在しない、ファイル名が変更された、またはアップロードが完了していない。
  • [virtual_sdcard] pathが誤ったディレクトリを指している。
  • ファイルのパーミッションが異常で、Klipperユーザーが読み取れない。
  • ファイル名に特殊文字が含まれており、特定のフロントエンドやシステムのパス処理で異常が発生する。
  • ファイルの印刷中または読み取り中に、仮想SDのオープン、選択、リセット、または書き込みコマンドを再度実行した。
  • Klipperのソースコードディレクトリ、設定ディレクトリ、またはその他の非G-codeディレクトリを誤って[virtual_sdcard] pathに指定した。

解決方法：

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

関連設定参考：設定変更説明。

MCU CRC does not match config / Can not update MCU config​

エラーメッセージ：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が再び接続または再設定しようとした際に発生する二次的なエラーである。調査時はログの最終行だけを見るのではなく、より早期に発生した最初の真のエラーを探すこと。

解決方法：

  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 ツールボードのファームウェアバージョンと上位機の Klipper バージョンが一致しておらず、上位機がこのファームウェアでサポートされていないコマンドを送信している。
  • 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

Shutdown due to M112 command / webhooks request​

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

解決方法：

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

上位機の性能不足による印刷のカクつき​

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

解決方法：

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

上位機の異常再起動 / システムクラッシュ​

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

よくある原因：

  • 上位機への電力供給不足。印刷中に USB、カメラ、ディスプレイ、ファンの負荷変動により電力が落ちる。
  • システムディスク、TF カード、eMMC の読み書き異常。ログが突然途切れたり、ファイルが破損する。
  • 上位機の CPU オーバーヒート。システムが保護のためにクロックダウン、フリーズ、再起動する。
  • USB 逆給電または周辺機器の供給経路異常。マザーボード、ディスプレイ、上位機が互いに影響を及ぼす。
  • サードパーティサービス、カメラストリーム、AI プラグイン、過剰な Web 接続がリソースを消費する。

調査方法：

電源オフ作業

上位機の電源ケーブル、USB ケーブル、ディスプレイケーブル、ファンケーブルを確認したり、配線を整理する前には、必ずプリンターの電源を完全に切り、電源供給から外してください。電源を分解したり、主電源配線を変更しないでください。

  1. まず klippy.log、moonraker.log、システムログを確認し、Klipper のエラーか上位機全体の再起動かを特定する。
  2. 上位機の電源仕様を確認する。電流不足や電圧降下が顕著な電源ケーブルは避ける。
  3. システムディスクの健全性を確認する。必要に応じて、信頼性の高い TF カード、eMMC に交換するか、システムを再書き込みする。
  4. 上位機の冷却を確認する。ファンが正常に動作し、ヒートシンクが密着し、筐体の通気が確保されていることを確認する。
  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

ステッパー作動中に時間をリセットできない​

エラーメッセージ：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サービスが自発的に再起動することです（ホスト側）：ログには、前の秒まで印刷していたStats統計行の直後に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の繰り返し再起動、実行中の未処理例外

Loading...