戻り値・通信異常・アラーム判定の実装照合

このページは source_reference/dobot_core/dobot_ctrl.py、dobot_tcp.py、dobot_error.py の静的照合結果である。実機での動作保証ではない。

戻り値の意味

API	正常系	異常系・注意点
`get_digital_input(index)`	DIがHIGHなら `True`、LOWなら `False`	Dashboardの非正常応答、解析失敗、値なし、例外も `False`。LOWと障害を戻り値だけで区別できない。
`get_IO(id_num)`	Feedbackの `digital_outputs` の指定ビットを `1` または `0` で返す	`id_num < 1` は `ValueError`。`_state()` が初回Feedbackを取得できなければ `RuntimeError`。初回受信後の鮮度は検査しない。
`set_IO(id_num, value)`	Dashboard `DO` 応答コードが0なら `True`	それ以外は `False`。出力の実際の切替やreadbackの一致を確認する処理ではない。
`reset_error()`	`ClearError` 応答コードが0なら `True`	それ以外は `False`。アラーム原因の解消は保証しない。
`get_motion_complete()`	`busy_status` が偽なら `True`	`busy_status` は `RunningStatus` と `JogStatus` を使用し、初回Feedback未取得では `RuntimeError` が伝播する。`True` は目標到達・アラームなしを保証しない。
`wait_for_complete()`	`Sync()` の正常応答後、検出されたアラームがなければ `True`	Sync応答失敗または検出アラームで `False`。通信・アラーム取得失敗をすべて検出するわけではない。公開 `DobotCtrl` は引数なし。
`get_error()`	アラームIDのリスト	Dashboard不在、GetErrorIDの異常応答、空・解析不能データは `[]` になり得る。
`get_error_code()` / `get_error_count()`	先頭ID / 件数	上記の障害時にも `0` になり得る。
`check_error()`	`get_error_count() == 0`	GetErrorID取得失敗でも `True` となり得るため、通信健全性の判定に用いない。

Feedbackとアラーム取得の境界

_state() は初回の有効なFeedback到着をEventで待ち、タイムアウト時に RuntimeError を送出する。ただし、初回受信後のタイムスタンプや最終更新からの経過時間は判定しない。motion_error_active() は _state_getter("ErrorStatus", timeout=0.1) の RuntimeError を捕捉して error_status=False とする。GetErrorID() が取得できず空のアラーム一覧になった場合、実際には確認できていないのに「アラームなし」と同じ判定に到達する経路がある。

運用上の帰結: False / 0 / [] / True を単独で通信健全性や動作安全の証明として扱わない。これは実装上の制約の記録であり、APIの動作を変更したものではない。

照合範囲と未検証事項

確認したのは提供されたPythonソースコードの分岐と戻り値である。実機のアラーム発生、通信断、I/O配線、TCPタイムアウト、Sphinx HTML生成の動作試験は実施していない。