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

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

このページでは、通信タイムアウト、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​

エラーメッセージ：ステッパーイベントが MCU で処理可能な時間範囲を超え、プリンターがシャットダウン状態になります。

Loading...

参考シナリオ：このエラーは必ずしもメッシュベッド設定によって引き起こされるわけではなく、実際の原因は klippy.log と現在の操作を組み合わせて判断する必要があります。多点プロービングベッドメッシュを実行する際、[bed_mesh] の probe_count が大きすぎる設定で、かつ高い mesh_pps を設定している場合、過密なメッシュデータが生成され、ホストコンピュータの計算とモーションプランニングへの負荷が増加する可能性があります。

解決方法：

  1. 多点プロービングベッドメッシュ中にエラーが発生した場合は、まず [bed_mesh] の probe_count を減らします。例：7,7 または 9,9 に変更してテストします。
  2. 高い mesh_pps を設定している場合は、その設定値を下げるか削除します。例：mesh_pps: 2,2 に変更します。
  3. 設定を保存し Klipper を再起動した後、エラーが発生した操作を再実行します。
  4. それでもエラーが発生する場合は、ホストコンピュータの負荷、印刷速度、加速度、通信品質、現在実行中のマクロや G-code を引き続き確認します。

関連設定のリファレンス：マクロの紹介、よく使うデバッグディレクティブ。

MCU 'mcu' shutdown: Timer too close​

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

Loading...

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

解決方法：

  1. ステッパーモーターのマイクロステップ数を減らし、MCU のパルス処理負荷を軽減します。
  2. 印刷速度と加速度を下げて、問題が解消されるか確認します。
  3. ホストコンピュータの負荷、電源、USB/CAN 通信品質を確認します。
  4. 電源を切った状態で、MCU とホストコンピュータ間の通信線がモーター線、ヒーター線、ヒートベッド線、電源線の近くに配線されていないか確認します。必要に応じて配線し直すか、シールド付き通信線に交換します。
  5. マシンのアース接続を確認する場合は、メーカーが指定するアースポイントとコンセントの状態のみを確認し、電源を分解したり商用電源のアース線を変更したりしないでください。
  6. 問題がホーミング段階で発生する場合は、ホーミングタイムアウト問題 を参照してください。
  7. 問題が解決しない場合は、ホストコンピュータのシステムまたはファームウェアの再書き込みを検討します。

関連設定のリファレンス：よく使うデバッグディレクティブ、ホーミングと方向校正ガイド。

Rescheduled timer in the past​

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

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

解決方法：

  1. NTP 同期が有効になっている場合は、一時的に無効にしてテストします。
  2. ホストコンピュータで実行中の他のサービスの負荷を減らします。例：不要な Web インターフェースやカメラストリームなどを停止します。
  3. 仮想マシン上で実行している場合は、物理マシンへの移行や、より安定したクロックソースの使用を検討します。
  4. ホストコンピュータの CPU 使用率を確認します：htop コマンドで klippy プロセスの CPU 使用率が異常に高くないか確認します。

関連設定のリファレンス：よく使うデバッグディレクティブ。

Internal error on command​

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

一般的な原因：

  • マクロまたは G-code コマンドが Klipper 内部の Python 例外をトリガーした。
  • 設定ファイル内に、誤ったマクロ参照や Jinja2 テンプレート構文エラーが存在する。
  • Klipper のバージョンと設定ファイルの形式が互換性がない。
  • G-code ファイル名に特殊文字が含まれており、エンコーディングエラーが発生している。

解決方法：

  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 ファイル名を英数字、アンダースコア、またはハイフンのみに変更します。

関連設定のリファレンス：マクロの紹介、設定変更の説明。

Unable to open file​

エラーメッセージ：ファイル印刷時に Unable to open file と表示される。

一般的な原因：

  • G-code ファイルが存在しない、ファイル名が変更された、またはアップロードが完了していない。
  • [virtual_sdcard] path が誤ったディレクトリを指している。
  • ファイルのパーミッションが異常で、Klipper ユーザーが読み取れない。
  • ファイル名に特殊文字が含まれており、一部のフロントエンドやシステムのパス処理で異常が発生している。

解決方法：

  1. Web インターフェースから G-code ファイルを再アップロードし、ファイル名が印刷コマンドと一致していることを確認します。
  2. [virtual_sdcard] path が実際の G-code 保存ディレクトリを指しているか確認します。
  3. ディレクトリのパーミッションを確認します：ls -la ~/printer_data/gcodes/。
  4. ファイル名を英数字、アンダースコア、またはハイフンのみに変更してから再テストします。

関連設定のリファレンス：設定変更の説明。

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'。

解決方法：

  1. FIRMWARE_RESTART を実行します。必要に応じて、本体の電源を 10 秒間切り、再投入します。
  2. klippy.log で最初に表示されているエラーを確認し、シャットダウンの根本原因を先に修正します。
  3. 複数 MCU のマシンの場合、[mcu]、[mcu xxx] の USB ID または CAN UUID を一つずつ確認します。
  4. Klipper を更新したばかりの場合は、すべての MCU ファームウェアを再コンパイルして書き込みます。

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. ホストコンピュータのパフォーマンスが本当に不足している場合は、より高性能なホストコンピュータへの交換を検討します。

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 ファイル内に循環参照がないか確認します。

Loading...