# Coordinate conversion and motion API boundaries

This page consolidates the public interface in `source_reference/dobot_core/dobot_ctrl.py` and the existing implementation audit. It does not claim hardware validation.

## Delegation

`DobotCtrl.p2j(p_type_pos)`, `j2p(j_type_pos)`, and `dev(base, offset)` delegate to the corresponding `DobotTcp` methods. `DobotCtrl.move()` forwards `target`, `motion_mode`, `coord_type`, `path_blend`, `offset`, `pose`, `speed`, `accel`, `decel`, and `is_async` to the backend. A public parameter is not proof that its behavior is implemented.

## MG400 coordinate constraints

The shared Cartesian representation is `[x, y, z, rx, ry, rz]`; MG400 uses `[x, y, z, r]`, with `r = rz`. Independent `rx` and `ry` rotations cannot be realized. The shared joint representation is `[j1, j2, j3, j4, j5, j6]`, while MG400 only drives J1–J4. Unsupported components must not be assumed to be silently valid.

## Motion support

Previous source audits map Cartesian PTP to `MovJ`, Cartesian LINE to `MovL`, and joint PTP to `JointMovJ`. Semantics-preserving CIRCLE/SPLINE support, trajectory generation for `rotate()`, and some options such as `path_blend` remain unimplemented or unverified. `is_async=False` uses `Sync()`, but that alone does not establish healthy communication or an alarm-free completion.

## Verification scope

This is static source analysis, not a hardware test. Coordinate frames, joint limits, and fault behavior require controlled verification with the robot and its safety procedures.