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

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

このページでは、通信タイムアウト、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 が発生する可能性があります。

解決方法：

  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）の処理負荷が高い、ホストコンピュータの応答がタイムアウトしている、印刷速度が高すぎる、マイクロステップ数が高すぎる、システム時刻の同期が干渉している、または MCU 通信線が干渉を受けている可能性があります。

解決方法：

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

関連設定の参考：一般的なデバッグディレクティブ、ホーミングと方向校正ガイド。

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 使用率が異常でないか確認します。

関連設定の参考：一般的なデバッグディレクティブ。

Internal error on command​

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

一般的な原因：

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

解決方法：

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

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

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 コードファイルが存在しない、ファイル名が変更された、またはアップロードが完了していない。
  • [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 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 が既に shutdown/error 状態にある後に、Klipper が再度接続または再設定を試みた際に発生する二次的なエラーです。調査時はログの最後の行だけを見ずに、より早い時点で発生した最初の実際のエラーを確認してください。

解決方法：

  1. FIRMWARE_RESTART を実行し、必要に応じて本体の電源を 10 秒間完全に切ってから再投入します。
  2. klippy.log でより早い時点で発生した最初の shutdown、Timer too close、Lost communication、Verify heater、TMC または温度エラーを確認し、まず shutdown の根本原因を修正します。
  3. 複数 MCU のマシンでは、[mcu]、[mcu xxx] の USB ID または CAN UUID を一つずつ確認します。
  4. Klipper を最近更新した場合は、全ての MCU ファームウェアを再コンパイルしてフラッシュします。
  5. [mcu host] を使用している場合は、klipper-mcu サービスが正常に起動しているか確認し、その後 Klipper を再起動します。
  6. プリインストールまたはカスタマイズされた Klipper システムを使用している場合は、ログが完全で、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. スライサーが G2 / G3 円弧を出力している場合は、円弧フィッティングの提案 を参照して調整するか無効にします。
  5. ホストコンピュータの性能が不十分な場合は、より高性能なものへの交換を検討します。

ホストコンピュータの異常再起動 / システムクラッシュ​

エラーメッセージ：印刷中に Klipper / Moonraker が突然切断され、klippy.log が突然途切れ、明確な shutdown の根本原因がない。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 ファイルに循環参照がないか確認します。

Loading...