Liquid handling in Antha is designed to operate on a device-independent basis, including both automated and manual execution. The key goals of the liquid handling system are
Some aspects of the system are presently better defined than others and it is currently in an experimental stage prior to further testing.
The core of the system is the mix command. There are two versions, mix and mixinto. Using mix implies that the system will find a destination for the resultant mixture, while mixinto allows the user to specify which plate to use as destination. The system will decide which well to use.
The requirements of mix are a set of liquids and how much of each is needed. To specify this there are three functions available for the system: Sample, SampleForConcentration and SampleForTotalVolume, which deal with volume, concentration and ‘make up’ volume components respectively.
Sample is the simplest and just specifies a fixed volume to be taken, it takes a liquid and a volume parameter.
SampleForConcentration tells the mixer to aim for a goal concentration. The component stock concentration is specified as part of the input (and the system may request changes if this is permitted). The system will calculate how much volume given the stock concentration will be required to achieve your target.
To use this it is necessary to state what the total volume of the mixture will be, necessitating the use of the following sample method.
SampleForTotalVolume specifies the system should use the specified component to make the total volume of the mixture up to the stated level. So if the total volume of all the other components is 15ul and 20ul are required the system would add 5ul of the specified component to make up the remaining volume.
Mix is then called with a set of samples which will be mixed in the
order specified. At present a mix corresponds to a
The core of the system is the set of liquid handling policies, which, along with the instruction system, are designed to provide a flexible way to change what the liquid handler actually does to move components.
The policy system has two sides to it: rules and
The preconditions required can be one of two classes, either categoric items, such as liquid classes, which are identified by strings or numeric items such as volumes which take an upper and lower limit and are active if the tested value is between the two limits.
Parameters which can be tested are based on the parameters of the relevant command. These should be intuitively named and be in ALL CAPS.
Some examples are
For the first release the only conditions which exist are on the liquid classes. There are seven of these: water, culture, glycerol, solvent, default, foamy and dna.
Policy management is not yet fully implemented but the structure will
work in the following way: there are three levels of policies, system,
At present these commands are fairly low-level including features such as the Z offset required when aspirating or dispensing or the pipetting speed. A list of the most important appears below:
The system uses a domain-specific language for defining the sequence of liquid handling operations. The language consists of a hierarchy of instructions with increasing specificity.
At the highest level is a single instruction: Transfer. This takes as
The transfer instruction is designed to encapsulate a whole set of operations which form a stage in the liquid handling process. One way to think of it is a set of instructions which might make sense to do without changing tip (although the system will most likely change tips several times in all but the simplest cases) – such as when you’re only pipetting one component around.
Transfer is broken down into specific liquid handling instructions in stages. First the CAN_MULTI parameter is consulted and if set the system looks for opportunities to do multichannel operation based on the configuration of the loaded pipettor head: number of channels, orientation etc.
Multichannel operations are performed as far as possible, following which single channel operations are used to deal with anything left over. Each transfer is split up to account for minimum and maximum volumes based on the limits of the channel type.
Each single or multichannel transfer operation is then turned into a
number of suck and blow steps which represent taking up and putting down
liquids. This level is where the main bulk of the actions associated
Following this the lowest level of instructions are generated, these can be directly translated into the more familiar liquid handling instructions such as aspirate, dispense and move. These then turn into driver calls for the particular instrument.
The system does a lot of work to make planning and scheduling a liquid handling request possible. The beginnings of this are in place but there’s still a long way to go. At present the system can accommodate requests from a single thread of execution to be executed in one block rather than continuous requests, this is partly a limitation of planning and partly a case of the current driver status: as it stands, drivers for liquid handling are being generated and executed as batch processes, which limits the possibility for feedback within a single process although with further developments in the AnthaOS it will still be possible to bake in a fair bit of logic.
The system plans requests based on a set of input and output plates and
tips which are specified by the user. In the earliest versions this is
most easily done via the
This has been a brief overview of the initial implementation of the Antha liquid handling framework. We expect rapid changes to this over the coming months so keep testing and if you have any ideas, questions or requests please get in touch!