# Public API return and failure semantics: quick reference

This table records a static source-level contract based on the supplied `DobotCtrl`, `DobotTcp`, and `DobotErrorManager` implementations. API return values do not by themselves establish physical motion completion or communication health.

| API | Return | Interpretation / limitation |
| --- | --- | --- |
| `get_digital_input(id_num)` | `True` / `False` | `False` conflates DI LOW with read/parse failures. |
| `get_IO(id_num)` | `0` / `1` | Reads a DO bit from feedback; initial feedback failure raises `RuntimeError`; freshness is not checked thereafter. |
| `set_IO(id_num, value)` | `True` / `False` | Dashboard command acknowledgement; does not verify physical output or readback. |
| `reset_error()` | `True` / `False` | ClearError acknowledgement; does not establish that the underlying cause is resolved. |
| `get_motion_complete()` | `True` / `False` | Negation of busy status, not proof of target reached or alarm-free execution. |
| `wait_for_complete()` | `True` / `False` | Depends on Sync response and detectable alarms; does not identify every communication failure. |
| `get_error()` | alarm IDs / `[]` | `[]` may mean no alarms or failure to retrieve alarms. |
| `get_error_code()` / `get_error_count()` | integer (including `0`) | `0` does not rule out a retrieval failure. |
| `check_error()` (backend) | `True` / `False` | `True` does not prove communication health; this is not a same-named public `DobotCtrl` method. |

## Distinct completion boundaries

HTTP 200, motion command acceptance, a `Sync()` reply, the last received feedback, and arrival at a target are distinct events. Do not blindly resend a motion command after a timeout.

See the [return/failure audit](return_failure_contract_audit.md), [HTTP contract](http_contract_audit.md), and [feedback/error audit](error_feedback_audit.md). Hardware and disconnect testing have not been performed.