# Source audit: I/O, state and error handling

This page records static findings from `source_reference/dobot_core/dobot_ctrl.py` and `dobot_tcp.py`. It does not establish hardware behavior.

## I/O

- `get_digital_input(id_num)` delegates to `DobotTcp.get_digital_input(index)`, which calls Dashboard `DI(index)` and converts a valid response to `bool`.
- `get_digital_input()` also returns `False` on protocol errors, malformed replies, and exceptions. **A `False` result cannot distinguish a low input from a failed read.** Do not treat it as a validated safety interlock.
- `get_IO(id_num)` is a DO readback, not a DI read. It inspects the feedback `digital_outputs` bit at `id_num - 1`; values below 1 raise `ValueError`.
- `set_IO(id_num, value)` sends `DO(int(id_num), int(bool(value)))` and reports whether the first reply code is zero. It does not verify the physical output after the command.

## Status and completion

- `servo_on` converts feedback `EnableStatus` to a Boolean; it is not a motion-running indicator.
- `get_motion_complete()` returns `False` when `busy_status` is `None`, otherwise the negation of that status. It does not prove successful arrival or absence of alarms.
- `wait_for_complete()` issues Motion API `Sync()` and checks its response and motion errors. Backend `timeout` and `interval` are unused; public `DobotCtrl.wait_for_complete()` takes no arguments.

## Errors

- `reset_error()` sends Dashboard `ClearError()`. It does not establish that the root cause has been removed or the system is safe to resume.
- `get_error()`, `get_error_code()`, `get_error_count()`, and `get_error_info()` delegate to `DobotErrorManager`. Their complete return/exception contracts require review of that class.

## Not yet verified

Hardware DI/DO mapping, feedback freshness, disconnect behavior, alarm recovery, and Sphinx HTML output have not been verified.