suzuke.page
← 記事一覧に戻る

Ender-3 V3 Plus CL2529エラー修理メモ

CL2529エラーの原因をソースコードレベルで解析し、printer.cfgの設定変更だけで解決した記録

Assisted by Claude Opus

Ender-3 V3 PlusKlipperCL2529トラブルシューティング

症状

Ender-3 V3 Plus でプリント開始時のレベリング中にCL2529エラーが頻繁に発生していました。

  • プリント開始時の初回レベリング（G28 Z）で警告画面が表示される
  • エラーコード：CL2529
  • 「続行」ボタンを押すと、再度レベリングを実行して正常に印刷が開始される
  • 頻度は高く、体感でかなりの割合で発生

調査

1. Klipperログの分析

cat /usr/data/printer_data/logs/klippy.log | grep -i "error\|529\|probe\|tri_"

ログから以下のことが判明しました。

  • エラーメッセージ: PR_ERR_CODE_G28_Z_DETECTION_TIMEOUT: G28 Z try probe out of times.
  • 内部コード: key529
  • 底面に配置されている、4つのストレインゲージセンサー（CH0〜CH3）でプローブ圧力を測定
  • CH3のセンサー値に異常なスパイクが発生していた
[PRES_CH3] [..., 324110.000, -980617.000, ...]

正常なチャンネルが徐々に増加する値を示すのに対し、CH3は 324110 → -980617 と極端に跳ねており、これがノイズ（誤作動）の原因です。

2. プローブ結果のばらつき

3回のプローブ結果を比較すると：

[G28_FIRST_MMS] [2.763, 3.248, 4.132]

2.763mm と 4.132mm の差が約1.4mmもあり、一貫性がありませんでした。この「ばらつきが大きすぎる」ことがタイムアウトの直接原因です。

3. バイナリの解析

プローブ処理のコアロジックは以下のコンパイル済みバイナリにありました。

/usr/share/klipper/klippy/extras/prtouch_v1_wrapper.cpython-38-mipsel-linux-gnu.so

strings コマンドで内部文字列を抽出した結果、重要なパラメータ名が見つかりました。

strings prtouch_v1_wrapper.cpython-38-mipsel-linux-gnu.so | grep tri_

tri_try_max_times
tri_min_hold
tri_max_hold
tri_hftr_cut

これらは printer.cfg から読み込まれる設定パラメータであることが分かりました。

4. ソースコードの発見

決定的だったのは、Crealityが2025年12月にGPLライセンスに基づき、prtouch_v1_wrapper.py のPythonソースコードを公開していたことです。

ソースコードから、エラー発生ロジックが明確に判明しました。

エラー定義：

PR_ERR_CODE_G28_Z_DETECTION_TIMEOUT = {
    'code': 'key529',
    'msg': 'PR_ERR_CODE_G28_Z_DETECTION_TIMEOUT: G28 Z try probe out of times.',
    'values': []
}

リトライ上限の設定：

self.tri_try_max_times = config.getint('tri_try_max_times', default=10, minval=0)

printer.cfg に書かれていない場合、デフォルトは10回。0に設定するとチェック自体が無効化される。

エラー判定ロジック：

if self.tri_try_max_times != 0:
    if use_tri_times == self.tri_try_max_times:
        self.print_msg('WHY ERROR',
            "FUN:G28_Z Coarse Probe Out of max {} times:{}...".format(...))
        self.ck_and_raise_error(True, PR_ERR_CODE_G28_Z_DETECTION_TIMEOUT)

tri_try_max_times != 0 の場合のみエラー判定が行われるため、0に設定すればエラー判定自体がスキップされます。

「続行」ボタンの動作

エラー発生後にプリンターに搭載されている画面で「続行」を押した場合の動作も分かりました。

CL2529 エラー発生
  ↓
ck_and_raise_error() 実行
  ├─ ノズルを5mm退避（安全措置）
  └─ raise self.printer.command_error(...)  ← 警告表示
  ↓
ユーザーが「続行」を押す
  ↓
SET_KINEMATIC_POSITION → 現在位置を再設定
  ↓
G28 Z を最初からやり直す
  ↓
今度は全CH正常 → プローブ成功 → 印刷開始

つまり、エラーは command_error（警告レベル）であり、Klipperのシャットダウンではありません。「続行」を押すと最初からレベリングをやり直し、2回目は通常正常に完了します。

解決策

printer.cfg の [prtouch_v2] セクションに tri_try_max_times: 0 を追加します。

ssh root@192.168.0.230
vi /usr/data/printer_data/config/printer.cfg

[prtouch_v2]
# ... 既存の設定 ...
tri_try_max_times: 0

また、エラー履歴の表示をクリアするため、fault_code_info.json を初期化します。

echo '{"list":[]}' > /usr/data/creality/userdata/fault_code/fault_code_info.json

最後にKlipperを再起動して反映します。

/etc/init.d/S55klipper_service restart

安全性について

tri_try_max_times: 0 はエラー判定を無効化するだけで、プローブ動作自体は正常に行われます。ソースコード上、この値が 0 の場合はリトライ上限チェックのif文自体がスキップされるだけで、プローブの精度やレベリング品質には影響しません。

実際に「続行」ボタンでやり直した場合にほぼ成功することからも、センサーの一時的なノイズが原因であり、プローブのリトライで十分に補正されていることが裏付けられています。

ハードウェア的な改善

今回はソフトウェア側の設定変更で対処しましたが、根本原因はベッド底部に取り付けられている4つのストレインゲージセンサーのうち、特にCH3が異常なノイズを出していることにあります。

設定変更はエラー判定を回避するだけであり、センサー自体のノイズが解消されるわけではありません。ストレインゲージセンサーの交換により、プローブ精度そのものが改善し、ばらつきのない安定したレベリングが得られる可能性があります。