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, HTTP contract, and feedback/error audit. Hardware and disconnect testing have not been performed.