# エラー管理とFeedback通信の実装検証

本書は提供された `dobot_error.py` と `dobot_tcp.py` の静的解析結果であり、実機動作の保証ではありません。

## DobotErrorManager

- `DobotTcp` は `DobotErrorManager` にDashboard取得、Feedback状態取得、値のスカラー化、ロガーを注入する。エラー管理クラス自体はTCP接続を所有しない。
- `GetErrorID()` の応答コードが0以外、Dashboardが未接続、応答が空、JSON形式が不正の場合、`_get_error_records()` は空リストを返す。**空リストはアラームが存在しないことの証明ではない。**
- `GetErrorID()` の配列の第1群をcontroller、第2群以降をservoとし、後者の群番号を `joint` として保持する。
- アラーム説明は `jp` → `ja` → `en` の順に選択する。IDだけから説明を取得するときはcontrollerを優先するため、発生元の区別が必要な場合は `get_current_error_info()` を使用する。
- `get_error_code()` はレコードがないと0、`get_error_info(index)` は範囲外で `None` を返す。ここでの `index` は **0-based** であり、ロボット軸番号とは異なる。
- `motion_error_active()` はFeedbackの `ErrorStatus` を調べ、必要時に `GetErrorID()` を問い合わせる。状態取得で `RuntimeError` が起きると `ErrorStatus=False` として継続するため、**通信障害を正常状態と判定する危険がある**。`wait_motion_start_or_error()` は受付直後の短時間監視であり、移動全期間の成功を保証しない。

## DobotTcp Feedback

- `connect()` はDashboard・Motion・Feedbackの3ソケットを生成し、Feedback受信スレッドを起動する。戻り値 `True` は有効なFeedbackフレーム受信完了を意味しない。
- 受信ループは1440 byteに達するまで蓄積し、`test_value` が一致したフレームのみを採用する。状態更新にはロックを使う。
- FeedbackのEOF時にはFeedbackソケットを再接続するが、例外時はログ出力と短時間sleep後の再試行であり、**例外時に再接続されるとは限らない**。
- `_feedback_ready` は最初の有効フレームでセットされる。以降の通信停止時にクリアされないため、`_state()` が返す値は**最新受信値であって鮮度保証付きの現在値ではない**。
- `is_connected()` は3つの接続オブジェクトが `None` でないことを確認するだけで、実際のTCP疎通やFeedback鮮度は検査しない。
- `disconnect()` は停止イベント設定、ソケットクローズ、状態クリアを行うが、受信スレッドの `join()` は実行しない。

## 運用上の制約

安全インターロック、停止保証、アラーム解除後の自動再開判断に、上記のBoolean値やキャッシュ済みFeedbackだけを使用してはならない。通信断・未取得・アラームなしを区別する追加設計が必要である。