エラー管理と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だけを使用してはならない。通信断・未取得・アラームなしを区別する追加設計が必要である。