Known limitations

These limitations affect task execution, device behavior, and deployment. Check the relevant entries when selecting a workflow or diagnosing a failure.

Execution semantics

Area	Current limitation	What this means for use
Preview	Only `moveto` and `end_effector`; MoveIt still initializes	Preview checks supported motion plans; it does not simulate an entire experiment or isolate every device
Unbatched preview	Every row starts from live `CurrentState`; the GUI replaces each displayed preview	Success does not validate transitions between rows; use an eligible batched preview for a connected sequence
Mock hardware	Mock UR control does not automatically disable all devices	Explicitly disable vision/pipettor and restrict the introductory task
2FG7 mock mode	CMS launch supplies `use_fake_hardware`, but the local driver reads `use_mock_hardware`; serial connection remains possible	Use the first-task ePick demo, which avoids this driver; see the driver limitation
Cancellation	Behavior depends on batch and child-action execution boundaries	Software cancellation is not a hardware emergency stop
GUI Stop	Cancellation takes effect at backend execution boundaries; the GUI waits for the terminal result	Requesting Stop does not mean motion has already ended; see execution controls
ePick vacuum monitoring	Subscription and loss-abort checks are disabled in the orchestrator	A lost vacuum does not trigger the orchestrator’s automatic abort path
ePick batch breaker	Batcher groups by task type; there is no action-specific breaker hook	A vacuum-on task can share a batch with adjacent movements
Trajectory cache	Resolved poses are keyed, but live scene changes and model-file contents are not	Gripper/cup identity does not prove the surrounding geometry is unchanged; see cache behavior
Cached replay failure	Any returned error except `REPLAY_TIMEOUT` falls back to fresh planning and execution of the whole eligible batch	Earlier physical effects may repeat after a terminal failure; see replay failure handling

Vision, pipettor, and survey

Area	Current limitation	What this means for use
Vision scan cache	Scan and unified vision servers own separate process-local engines	A completed scan does not populate the unified vision server’s detection cache
Detect-only vision	Approach execution is skipped for the applicable path, but scan moves can still occur; `j6_snap` ignores the flag	Detect-only requests can still cause motion
Vision scan constraints	Multi-position and standalone scan helpers do not accept path constraints	Task constraints apply to supported approach/execution paths, not every scan movement; see task fields
Pipettor volume	EROBS forwards `volume_pct`, but the imported pipette driver uses fixed SUCK/EXPEL sequences	Changing the JSON fraction does not change those actuator sequences; see pipettor operations
Survey `--dry-run`	Live survey still moves; recording is suppressed	Use its offline merge or logic checks for hardware-free work

Deployment and integration

Optional servers: vision and pipettor default to disabled. Disabling vision also suppresses the sample server, including its legacy non-vision pick/place endpoints.
Tool change: MoveIt relaunch follows an actual tool/model transition; same-tool requests can return early without relaunching it.
CMS geometry: ePick configuration contains an explicit approach compensation, and some model/calibration work remains to be validated physically.
GUI portability: saved-run and some resource paths retain CMS assumptions. Changing the beamline name alone does not make the GUI deployment-neutral.
Agent/chat: experimental; implementation and current endpoint/credential handling take precedence over older README descriptions.
Bluesky/ZED/LIX/PDF: code and assets exist, but current end-to-end operation remains unverified. The integration guides distinguish demonstrated source defects from untested behavior.
Containers: recipes differ in build inputs and source provenance. Current ignore rules conflict with the minimal image’s local source copy assumptions; older VNC and interface examples are not reliable launch instructions.

Recorded deployment findings

Known CMS hardware issues: gripper steps reporting success before the fingers settle, and intermittent controller timing faults. Incomplete process cleanup after shutdown and tool exchange was also observed. The current shutdown behavior addresses it in source but has not yet been rechecked on the hardware.

Historical notes

Use the current guides and source browser for implementation details.

Use the explanatory chapters for current behavior and the source browser to inspect the corresponding implementation.