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.

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.

One of the rigid pieces an arm is built from, joined to its neighbours by joints.

What sets the arm's reach is the distance between a link's joints, not the shape of the piece - the material can be any shape, and can overhang a joint at either end, without changing where the arm gets to.

What holds two links together and lets them move relative to each other, in the one way the joint allows and no other.

Some joints are driven by a motor and some pivot freely - a manipulator's are driven, which is how it can be told where to go.

A set of links and joints working together as one mechanism.

Not another word for a link: a link is one piece, a linkage is a machine made of several.

• Four-bar - four links in a closed loop, the commonest of them all. A windscreen wiper, a bicycle's rear suspension.
• Pantograph - extends and retracts along one line while staying parallel. A scissor lift, and the reach of an arm that telescopes.
• Slider-crank - turns rotation into a straight push. A piston and its crankshaft.
• Parallelogram - keeps a part level however the arm moves, which is why an excavator bucket holds its angle.

An arm whose reach extends and retracts on a pantograph has both, one inside the other.

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 pipette's 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.

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.

The end-effector that measures and moves a volume of liquid.

Air-displacement ones draw it with a cushion of air between the liquid and the piston, so only the tip is wetted; positive-displacement ones move it with a plunger travelling inside the tip, for liquids an air cushion handles badly. Pipettor and pipetter are the same word in other mouths - none of them names the multi-channel assembly, which is simply a pipette with several channels.

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.

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.

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.

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 whole space a site's automation stands in, and the outermost frame everything in it is stated against.

Its contents are whatever occupies the floor: devices, the transport that moves physical resources between them, benches carrying no automation at all. Measurements taken anywhere on site can be compared once each is resolved into the facility's frame.

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

An origin and a set of axes that give a measurement its meaning.

On its own, 300 mm says nothing; stated in a frame, it says how far a point sits from that frame's origin along one of its axes. An automation system carries several frames at once - the facility floor, a device's own body, a deck, an arm that is itself moving - and a number is transferable between them only once the frame it was measured in is known. A good share of positioning errors in integrated systems come from a value crossing a frame boundary without being converted.

Taking a resource from one place and setting it down in another - approach, take hold, carry, release, and back for the next one.

The archetypal robot action, and the material-handling counterpart of pipetting: one moves the vessel, the other moves what is in it.

Most of what a lab arm does is a variant of it, which is why it is rarely counted on its own: the industry classification files picking and placing together with packaging, inside handling operations, rather than giving it a class of its own.

Loading a device and unloading it again - a plate into a reader, a centrifuge or an incubator, and out of it when the device is done.

Named for what it replaces: a person standing at a machine, feeding it.

What separates it from the work it serves is that the robot does not perform the operation. It is an assistant process around a primary one, and the industry classification draws the line there rather than at the equipment: a robot that reads the plate is doing measurement, a robot that hands the plate to the reader is tending it.

Building a pile of resources, or taking one apart.

Manufacturing and logistics call the same action palletising, after the pallet the goods are stacked onto, and it is the older name by a long way - old enough to hold a class of its own in the industry classification, across all sectors and every size of pallet, while picking and placing shares one with packaging.

In a lab the pile is plates or lids rather than cases, and what makes it its own action rather than a run of pick and place is that each item's place depends on how many are already there: the arm has to know the height of the stack it is adding to, and a plate hotel is the fixture that makes that height predictable.

Moving resources by what they are rather than where they are: reading an identity and sending each one where that identity says.

It is the one action here that cannot be run open-loop - every other one can be commanded from a fixed list of positions, and this one needs a reading first.

Logistics calls it sortation and states it as a sequence: merge, identify, induct, then convey to a specific destination. A plate handler with a barcode reader runs the same four steps at a different scale. Cherry-picking is sorting at well level rather than plate level, and moves liquid rather than the vessel.

Running a protocol against models of the devices rather than the devices, so it can be checked before anything moves.

A simplified shape standing in for a real one, used to ask whether two things would touch.

Kept deliberately coarser than the real geometry, because the question is only ever "would this hit" and a simpler shape answers it faster and more safely.

Preparing a model so it can be posed: giving it an armature and deciding how the geometry follows it.

Blender puts it as the controls and strings that move a marionette. The word comes from animation, and it describes the preparation, not the mechanism - a rig can be built for a mechanism that could never exist.

How many independent ways a mechanism can move.

One per joint that can be driven on its own, so a six-axis arm has six, and a Cartesian robot moving in x, y and z has three. Fewer than six means some positions can be reached only in one orientation, or not at all.

Working out where the tool ends up from what the joints are doing.

Always has one answer.

Working out what the joints must do to put the tool somewhere.

May have several answers, or none - an elbow can often reach the same point bent left or bent right, and a point outside the work envelope cannot be reached at all.

Every joint's value at one instant, which together settle the shape the whole arm is in.

A six-axis arm's joint state is six numbers; give them all and there is nothing left to say about where the arm is. Forward kinematics turns a joint state into where the tool ended up, and inverse kinematics turns a wanted tool position back into a joint state - often into several, since an elbow can reach the same point bent either way.

The robotics vocabulary standard calls this a configuration, which is recorded here as another name for it rather than as the entry's own. That word already carries another job: the arrangement of modules a workcell is built from. A value that changes with every move is better not sharing a name with one that describes how a cell was assembled.

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.

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.

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.

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.

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.

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.

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.

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.