Glossary

A programmable multi-axis arm that positions an end-effector in space to move physical resources, or to carry a tool between locations.

Everyday use calls the whole moving mechanism a robotic arm; the robotics vocabulary standard is stricter, keeping arm for only the links and joints between the base and the wrist, counting the wrist separately, and calling the whole arm-and-wrist mechanism a manipulator. This entry follows everyday use.

Not to be confused with Manipulator

Reference ISO 8373:2021, Robotics - Vocabulary

The joints between the arm and the end-effector, which support it and set which way it faces.

The robotics vocabulary standard names these the secondary axes, against the arm as primary axes, so the boundary falls where the job changes rather than at any particular joint. Anatomy is a false friend here: the wrist is not counted as part of the arm, and what sits beyond it is not a hand but whatever does the task.

Reference ISO 8373:2021, Robotics - Vocabulary

The reference point on the end-effector that the robot's motion is programmed against, given as an offset from the wrist flange.

It sits at the business end - a gripper's jaw contact point, a pipettor's nozzle tip - so a move sends that point to a position rather than the wrist. Fit a different end-effector and the point moves with it.

Reference ISO 10218-1:2025, Robotics - Safety requirements

An end-effector for seizing and holding, so an arm can pick a plate or a tube up, carry it, and set it down.

The commonest end-effector in lab automation, because most transport is moving resources between locations rather than acting on them. Grippers are grouped by how they apply the force that holds the resource.

• Mechanical - closes onto it.
• Vacuum - sticks to it by suction.
• Magnetic - pulls on it, if it is ferrous.
• Adhesive - sticks to it, for surfaces too delicate to squeeze.

A lab usually meets the first two.

Industrial robotics calls what a gripper holds a workpiece.

Reference ISO 8373:2021, Robotics - Vocabulary

Moving a measured volume of liquid by drawing it into a tip and expelling it again.

Aspiration and dispense are its two halves, and a transfer is one of each.

Pipetting mode is whether a pipetting action moves liquid to a different container or keeps it in the same one.

A transfer moves a net volume from a source into a different destination container; a mix draws liquid up and returns it to the same container to homogenise it, moving none between containers.

Dispensing mode is a classification of how liquid is released to its target destination.

Moving the tip vertically to track the liquid surface as it rises or falls, keeping the tip at a constant immersion depth - instead of holding a fixed height, where immersion drifts as the level changes.

Usually driven by liquid level detection.

A parameter set defining how a specific liquid transfers: flow rates, air-transport volumes, blow-out volumes, swap speeds, settling times and correction curves.

Measuring what happens during a liquid-handling step, and in some cases acting on the measurement.

This is the liquid-handling case of process monitoring and control, the engineering and manufacturing discipline of comparing a process against its intended behaviour - monitoring - and correcting it through a feedback loop - control. The measurements are taken inside the pipetting channel and at the tip: the pressure as liquid moves, the capacitance as a conductive tip meets a conductive liquid, and the height of the liquid surface. Monitoring identifies a blocked tip, an empty well, a short sample, or a surface that is not at the expected height; control responds to the measurement, for example by holding a volatile liquid in the tip. The pressure-based methods below carry Hamilton's names, though the underlying principles are general and other manufacturers implement their own.

Reference Wikipedia: Process control

The capability of being commanded to a target temperature and holding samples there, heating and/or cooling as needed to reach and maintain the setpoint.

Two kinds differ by what is driven to the setpoint: the material, through contact with a heated or cooled block, or the air enclosed around it, as in an incubator or a chamber - the sample changes temperature by conduction in the first case and by convection in the second. Either way it is driven by powered elements: a resistive heater, a Peltier element or a compressor. A passive insulated or pre-conditioned block that merely holds its temperature for a time does not offer this capability - there is no setpoint to command, so there is nothing for a protocol to call.

Not to be confused with Thermocycler

The capability of being commanded through a programmed sequence of temperature setpoints, driving samples between them rapidly and repeatedly and holding each only briefly before the next.

The fast, cyclic transitions are the point - as in PCR, which cycles between denaturation, annealing and extension temperatures many times over. The cycle is what gets commanded, which is what separates it from temperature control: a device that can only be sent to one setpoint at a time does not offer it.

Not to be confused with TemperatureController

The capability of being commanded to agitate a plate, mixing or resuspending its contents by moving it in the horizontal (x-y) plane.

It is commanded by amplitude - how far the plate travels - by speed, in revolutions or cycles per minute, and by the pattern the plate traces. A device offering this alongside temperature control is what is usually sold as a heater-shaker: two capabilities in one device, not a category of its own.

The capability of spinning samples so that denser matter is driven outward and settles, separating a mixture by density - pelleting cells, clearing a lysate, layering a gradient.

It is commanded by how hard it spins and for how long, and often by the temperature it holds.

The total volume occupied by all automation equipment connected into a single collaborating unit - the "unit cell" of an automation system.

The union of the work envelopes and footprints of every device that operates together (arms, liquid handlers, plate readers, decks, transfer stations), expressed in one shared coordinate frame.

The mechanism that moves physical resources between locations.

• Intra-workcell - within a single workcell: a robot arm or gripper passing a plate between devices.
• Inter-workcell - between separate workcells: a conveyor or a mobile robot linking cells.

The physical layout grid of a device where physical resources are positioned at defined locations.

What the host operating system needs before it can see the device at all: a USB, serial or network stack, or a manufacturer-supplied installer, kernel extension or device rule.

Usually owned by the operating system or the manufacturer rather than by a control library. Microsoft defines a driver at this layer by position rather than by hardware access: "any software component that observes or participates in the communication between the operating system and a device", which admits drivers that never touch hardware.

Reference Microsoft: What is a driver?

The layer that moves bytes to and from the device over a transport such as USB, serial, TCP or HID, without interpreting what those bytes mean.

The IVI Foundation calls this an I/O library, requires its instrument drivers to hand raw bus traffic to one, and does not call it a driver.

Reference IVI Foundation: driver architecture

The device-specific layer: it encodes the device's wire protocol, parses the responses, and exposes what the device can do as an API a protocol can call.

The layer a control library owns. The IVI Foundation defines its version by the capabilities implemented rather than by whether it addresses the hardware itself.

Reference IVI Foundation: IVI-3.1 Architecture

A major phase of a protocol with a distinct purpose of its own - binding, washing, eluting.

A procedure names why a group of steps exists rather than what commands they issue, so it is the level at which a protocol is discussed rather than executed.

Deciding when each step runs and on which device.

Lab automation treats this as an optimisation problem taken from operations research: of all the plans that obey the constraints, find the one whose last step finishes earliest. It works under different constraints from factory scheduling: biology bounds the gaps as well as the order - cells and unstable reagents degrade, so the time between two steps can itself be capped, and a step cannot simply wait for a device to come free.

Not to be confused with Orchestration

References Itoh et al. (2021), scheduling life-science experiments with time constraints Graham et al. (1979), the survey that formalised scheduling problems

A system or agent that performs a control task: it holds a run and decides what happens next as events arrive - an error, an unexpected result, a device coming free early.

The conditions each call is made under are part of it, not only their order, which is why an orchestrated run can absorb something going wrong where a script cannot. Its opposite is choreography, where devices follow an agreed exchange with no central conductor. Orchestration is a control problem where scheduling is an optimisation one, which is why the two answer different questions rather than competing for the same one. The name is musical, and it reached computing through web services rather than through operations research. Neither SiLA 2 nor OPC UA's laboratory standard defines the word, though both describe the role: SiLA as a process management system acting as a client to each device, LADS as a supervisory system overseeing lower-level subsystems.

Not to be confused with Scheduling

References SiLA 2 Part (A) v1.1, on a process management system orchestrating devices LADS (OPC 30500-1), defining the supervisory system Peltz (2003), Web Services Orchestration and Choreography Etymology of "orchestration"

Makes the parts equipment is built from: motors, pumps, valves, sensors, linear stages, optics.

Sells to equipment manufacturers rather than to laboratories, and often does not know which instrument a given part ends up in.

Designs and builds a laboratory device from parts, and defines the command set that device exposes.

It owns the firmware, so it decides what the device can be asked to do, and what it will refuse.

Connects devices into a workcell that runs as one collaborating unit: the physical layout, the transport of resources between devices, and the supervisory system that drives them.

Answers for the seams between instruments, which is where a workcell tends to fail rather than inside any one device.

Not to be confused with Programmer

Writes the automated protocols a workcell runs, and the instrument drivers those protocols reach the devices through.

Turns an intended experiment into commands a device will accept.

Not to be confused with Integrator

Runs the protocol on the hardware and is there while it executes: loading physical resources, starting the run, and judging whether what came out is sound.

The link that sees each individual run, rather than the design behind it.