# エラー取得・状態判定の多段呼び出し検証

対象は同梱 `source_reference/dobot_core/dobot_tcp.py` と `dobot_error.py` の静的ソース照合です。実機・通信試験ではありません。

## 呼び出し経路

| 公開API（`DobotCtrl` 経由） | `DobotTcp` | `DobotErrorManager` | 取得・判定処理 |
|---|---|---|---|
| `get_error()` | `get_error()` | `get_error()` → `_get_error_records()` | `GetErrorID()` 応答からID一覧 |
| `get_error_code()` | `get_error_code()` | `get_error_code()` → `_get_error_records()` | 先頭ID、レコードなしなら `0` |
| `get_error_count()` | `get_error_count()` | `get_error_count()` → `_get_error_records()` | レコード件数 |
| `check_error()` | `check_error()` | `get_error_count()` → `_get_error_records()` | 件数が0なら `True` |
| `get_error_info(index)` | `get_error_info(index)` | `get_error_info()` → `_get_error_records()` → `_error_record_info()` | 範囲外なら `None` |
| `get_current_error_info()` | 同名 | 同名 → `_get_error_records()` → `_error_record_info()` | 説明付きレコード一覧 |
| `error_description` | 同名プロパティ | 同名プロパティ → `get_current_error_info()` | レコードなしなら空文字 |

## 通信異常と正常値が合流する箇所

1. `_get_error_records()` は Dashboard オブジェクトが `None` の場合に `[]` を返す。
2. `GetErrorID()` の先頭リターンコードが0以外（または解析不能）の場合、ログを出して `[]` を返す。
3. `_parse_error_groups()` は空応答、括弧構造の不整合、JSON解析失敗、リスト以外の値で `[]` を返す。
4. したがって `get_error()` の `[]`、`get_error_count()` の `0`、`get_error_code()` の `0`、`check_error()` の `True` は、**アラームが存在しないことを一意には表さない**。
5. ただし `dashboard.GetErrorID()` 自体が例外を送出した場合は `_get_error_records()` に捕捉節がなく、その例外が伝播し得る。**あらゆる通信障害が空リストになるわけではない**。

## Feedbackを利用するモーションエラー判定

`motion_error_active()` は `_state_getter("ErrorStatus", timeout=0.1)` の `RuntimeError` を捕捉し、`error_status=False` に置き換える。`query_error_id=False` の場合、Feedbackからエラーを検出できなければ `GetErrorID()` を照会しない。`query_error_id=True` または `ErrorStatus=True` の場合は `_get_error_records()` を照会する。

`wait_motion_start_or_error()` は既定0.25秒の監視後、`query_error_id=True` で再判定する。これは**受付直後の限定的な監視**であり、移動全期間の成功確認ではない。

## 利用上の結論

- `check_error()` の真偽だけで通信正常を判断しない。
- エラーID取得失敗を確実に区別するには、現在の公開APIの戻り値だけでは不十分な経路がある。
- 例外の発生範囲は外部Dashboard実装に依存するため、ここでは保証しない。
- この資料は既存実装の観測可能な仕様を記録するもので、実装の修正は行っていない。