Experiment and Device Problems

Use the original run and request records to identify whether a problem occurred during checking, preparation, execution or finalization.

Gather the relevant records

Collect the run identifier, current or final status, affected operation, diagnostics and whether device effects were recorded. Ask:

Read this failed run's status and execution evidence. Explain where it failed, which actions are confirmed, what remains uncertain and which follow-up actions are currently available. Do not retry or change the workstation yet.

In the interface, read the outcome at the top of the experiment, then expand Technical details and execution records. Refreshing reads recorded facts; it does not inspect the physical instrument again.

Common problems

Symptom	Next action
Syntax or semantic error	Correct the reported source location, save and run Check again.
Missing driver	Install the compatible driver for the OS resident.
Device not configured	The driver exists, but this workstation has no matching device instance. Inspect its configuration.
Device disconnected	Inspect the connection/readiness of the configured instance.
Unsupported operation or parameter	Compare the requested operation with the actual driver capabilities and limits.
Position or binding mismatch	Match the program snapshot to the configuration; regenerate or review bindings as needed.
Insufficient tips or material	Read the specific resource and mode reported by the driver. Editing model records is not physical replenishment.
Configuration will not apply	Check for active runs, resource ownership, revision conflicts or an offline-only profile.
Body succeeded but finalization continues	Inspect cleanup and resource-release records and wait for the terminal outcome.
Control or configuration request unresolved	Query the original request status and retain its identity rather than duplicating the operation.
needs_reconciliation	Preserve run records, evidence and isolation. A general automatic retry or manual adjudication workflow is not available; contact the maintainer.

Simulated supplies and physical replenishment

The desktop Run simulation path starts from a fresh declared load. Persistent CLI station behavior is separate. Simulated tip replacement changes declared simulation state; it does not confirm a physical replacement. Use it only when the current driver and interface explicitly provide the relevant recovery path, not as a general solution to failures.

Adapt a mismatched experiment

Inspect the actual device and labware catalogue before treating a container or volume mismatch as a blocker. Ask the agent to propose a compatible substitute, explain its effect on the experiment and seek your approval before changing the source. Then repeat checking, loading preview and the relevant simulation.

A compatible carrier alone does not prove compatibility with mixing, incubation, separation or transport. If no supported alternative exists, report the remaining requirement clearly.

For separation syntax and retained container contents, use the Culsma separation guide. OS 0.2.0 supports explicit separation contexts; removing supernatant can leave sediment in its original container. This does not make every separation method available on every driver.

Detached fault tests

Supported drivers can show guidance for selected faults through Developer exception tests or the AI tool test_device_fault. This is a detached model test. It does not create a normal experiment, repair the active run or prove that the instrument recovered.

Pause and cancel do not replace physical emergency procedures. Follow the instrument's and laboratory's procedures when handling real equipment.