Liquid Handling

Liquid handling is the part of lab automation that moves liquids between containers. At its core, the SDK models this as a small number of primitives — aspirate, dispense, pick up tips, discard tips, transport labware — applied to a resource tree that describes your physical setup.

The SDK provides a high-level Python interface for controlling liquid handlers, covering aspirating, dispensing, tip handling, and labware transport. It abstracts vendor-specific differences so protocol code stays clean and portable across Hamilton, Agilent Bravo, and other supported handlers.

What the model captures

To command any liquid handler from Python, the SDK needs four things:

1. Labware definitions — what plates, tips, tubes, and carriers exist (Labware)
2. Deck layout — where each piece of labware sits (Deck)
3. A device connection — which physical handler receives commands
4. A set of instrument commands — what should happen, expressed as aspirate, dispense, pick_up_tips, etc.

The dependency is strict and the order matters:

Labware definitions  →  Deck layout  →  Device connection  →  Instrument commands
   what exists            where it is      who can act           what happens

Every liquid-handling call traces through this chain. aspirate(plate["A1"], volume=100) only works because plate["A1"] already has a known absolute_location computed from the deck, and because the device knows which pipetting module to use.

Vendor abstraction

Different liquid handlers work differently. Hamilton uses independent channels; Bravo uses a monolithic 96-nozzle head. Hamilton controls motion with flow rates in µL/s; Bravo uses velocity in mm/s. Hamilton requires an explicit liquid class; Bravo auto-selects one.

The SDK flattens these differences behind a shared set of concepts — Modules, Liquid Classes, Tips — so the same protocol shape works across vendors. Vendor-specific details show up as different parameters on the same methods, not as separate APIs.

Dry-running without hardware

Every device has a matching mock you can drop in without touching hardware. The mock runs the full liquid model — volume tracking, deck conflicts, tip state — locally, so you can validate a protocol end-to-end before a run. See Simulation.

Where to go next

• Your First Protocol — a runnable example that walks the full chain
• Labware, Deck, Modules — the building blocks of the model
• Basic Pipetting — the procedural how-to once the concepts are in place