What are the normal transfer states?
Your controls team defines the transfer sequence. We agree which platform functions, observations and status messages its software needs, such as carrier detection and handoff status. Station readiness comes from the system assigned to provide it. The sequence below is an example for discussing those interfaces.
- Source releases a carrier
- Identity and load are confirmed
- Mission is accepted
- Robot reaches the destination
- Receiver authorizes transfer
- Receipt is recorded
Which system owns each decision?
| Decision | Responsibility to assign |
|---|---|
| Release | Which laboratory or station controller authorizes the move? |
| Identity | Who reads and verifies the carrier ID and its contents? |
| Dispatch | Who selects the robot and target station? |
| Transfer permission | Who confirms that the receiver can accept the load? |
| Completion | Who records the final agreed physical and information state? |
| Recovery | Who reconciles state after a fault or manual intervention? |
How does the robot communicate with laboratory systems?
Before connecting the scheduler, record what each command requests, what each response confirms and what a timeout leaves unresolved. A working connection alone does not answer those questions. SiLA 2 exposes device capabilities through Features with Commands and Properties. If it is part of the chosen architecture, agree the actual implemented features and the project-specific meaning of each interaction.
We complete the hardware and firmware integration, then provide the agreed platform interface. If your software requires SiLA 2, we review the supported features and verify the required interactions before committing to that interface.
What happens when the normal sequence fails?
Define how the platform reports a missing load or unavailable receiver, and what state it enters. Your workflow owner decides whether to wait, request another destination or escalate to an operator. After a connection is lost during handoff, the authorized recovery process must establish the physical state before another transfer is requested; the hardware interface needs to expose the agreed observations and any unresolved status.
Repeating a transfer command without knowing whether the first attempt completed can create conflicting records or unintended movement. Assign recovery authority and define how a manual intervention is recorded.
- Unreadable or conflicting carrier identity.
- Correct task but wrong or missing physical load.
- Closed access route or unavailable destination.
- Interrupted handoff with uncertain load location.
- Low battery or communications loss during a mission.
What information should follow a transfer?
Agree a minimal record that identifies the carrier, task, source, destination and significant events. Decide whether the carrier represents a fixed list of samples and where that relationship is maintained. Record exceptions in a way the laboratory system can reconcile.
Avoid claiming an unbroken sample chain merely because the robot retains travel logs. Sample identity, custody and acceptance depend on the complete workflow and its operating procedures.
What would an unambiguous transfer record contain?
We agree the task identifier, carrier identity, event order and completion state with your software team. The table lists the information to exchange; field names and encoding belong in the project interface document.
| Information | Information to record | Why it matters |
|---|---|---|
| Task identifier | A unique task ID retained through acknowledgements, retries and the final result. | Distinguishes a retry from a newly requested physical task. |
| Carrier and endpoints | Carrier ID, pickup station and destination station. | Connects the physical object to the intended route and receiver. |
| Event identifier and order | A unique event reference and a task-state revision or sequence. | Allows duplicate or stale reports to be recognized. |
| Physical and workflow state | Arrived, transfer permitted, receipt confirmed, or a defined exception. | Separates position from successful transfer. |
| Time and reporting system | Timestamp with timezone and an agreed clock strategy; event source. | Supports reconstruction of the observed sequence. |
| Disposition | Accepted, rejected, unresolved or cancelled, with the agreed reason. | Provides the recorded outcome for the customer software to apply its workflow rules. |
If a completion acknowledgement is lost, the workflow owner should reconcile the existing task before issuing another physical transfer. Agree how the actual carrier location and receiver state are checked when software records disagree. Communication-level retry handling alone cannot prove where the carrier is.
Estimating transfer capacity
Start with measured times for loading, travel, docking, handoff and return or repositioning. Count waiting time whenever the robot remains occupied at a station.
For one robot completing one transfer per serial cycle: estimated transfers per hour = 3,600 ÷ mean cycle time in seconds.
Use the full cycle for the agreed carrier and route. Include charging, queues, interrupted transfers and operator recovery when estimating sustained capacity. For more than one robot, check shared routes, buffers and station availability with the scheduling team; multiplying one robot’s rate by the fleet size can overstate the result.
Manufacturing review inputs
- Carrier drawings and the permitted load configuration.
- Source and destination interface drawings.
- The state diagram and message definitions.
- Representative loads and station simulators for testing.
- Acceptance rules for normal and interrupted transfers.
Common questions
Is a successful drive enough to confirm delivery?
No. Delivery should be tied to the agreed physical handoff and receiving-system acknowledgement.
What if the robot carries several samples in one rack?
Define how the rack identity maps to its contents and which system maintains that relationship.
Can the robot integrate directly with any LIMS?
Do not assume universal compatibility. The chosen systems need explicit interface definitions and verification.
What does cancellation mean after a carrier has been collected?
Define it as a workflow decision with a known physical outcome. The task owner must specify whether the carrier is held, returned or sent to another authorized endpoint and how that disposition is recorded. Removing a task from a queue does not resolve the loaded carrier.
Can a communication standard define the whole transport workflow?
A standard can define how capabilities and information are exposed. The project still needs agreed task semantics, station readiness, physical receipt and exception ownership. Confirm the implemented features and test the complete interaction.
Technical references
The LabCarry hardware and customer software boundary
LabCarry completes the base and arm hardware/firmware connections and provides the agreed external platform interface. The customer connects its scheduling software to call supported device functions and receive their status.
Task priorities, sample identity rules, instrument coordination and application-level recovery belong to the customer workflow. Platform connection details, supported commands, states and firmware configuration belong in the agreed hardware interface handover.