I am looking at a relatively simple machine (SPT Apricot DC1). It does not seem to have eg. a drop function for the tip (I assume it auto-drops when you get a new tip with ‘Loadtip’). The machine has two locations where we can put a 96w tip rack, high-vol (10-1000uL) or low vol (1-125 uL). Depending on choice, the stock may need diluting (if vol too small for high-vol tip).
We want to dispense several ingredients for a design-of-experiment approach (eg. assay buffer optimisation), and each well is one mixture topped up to say, 1mL total with water.
Wat is best practice with regard to -
volume dispensing - largest volumes first, then smaller ones?
do you stick the tip in the well liquid, or hover above it?
do you use both low and high vol tips, or would you dilute stock suitably so you can use one?
reusing tips: one tip per dispense? Or one tip per ingredient for a multi-dispense; or is the risk of carry-over and contamination unacceptable? (I guess I could use one tip for all of the very first ingredient that I dispense)
I’m not thinking about robot arm travel distance yet, but that could be something to optimise as well I suppose in some cases (here it is less important).
Being a software developer mostly who stays away from a lab as far as possible I’d appreciate your insights and recommendations.
not a scientist either, but below is what I observed.
also: there is another, bigger general lab automation forum (not PLR specific) where a bunch of lab automation experts hang out: labautomation.io. it could be worth asking people there for more professional advice on these general best practice questions.
have you verified this on the machine? is there a discard function? it would be good to have certainty about the machine behavior before making a decision.
largest first. the smaller liquid will dissolve with the larger volume, aiding dispense. dispensing small volumes into an empty plate is hard due to surface tension of the droplet.
depends on the use-case. hovering over is good for avoiding contamination, if that is a concern, but going in the liquid might be more accurate
depends on the use case. assume if you re-use tips between wells that contamination will take place (plr actually checks for this automatically). for the first tip, as you say, this is not an issue
yes, deck layout optimization is a big topic in lab automation. in the past, i have used backtracking to optimize deck layouts wrt a protocol.
What a wonderful question; you are asking about liquid handler run management which very few people do, and the perfect topic for a software engineer to have a big impact.
This is all quite old now, and I might have worked on many of the kinks in the meantime but not in an open-source fashion (while my thesis is completely accessible to anyone )
Rick and I have had some conversations a long time ago about possibly integrating some of this into PLR but concluded that (at least for now) run management is completely on the user in PLR.
So let me answer some of your questions more directly:
drop_tip() → I agree with Rick that it is very important to check that there really is no function like this on your machine… If you don’t use this one the OT-2 and you ask it to pick up a new tip, the machine will crash its attached tip into the tip it is trying to pick up, not a nice sight.
large volume-first → again, completely agree with Rick: ideally you always dispense all your large liquid transfers first
Going a bit further, I would recommend for your DoE, especially at the beginning to get operational asap:
calculate all your DoE factor level permutations,
store them however you want (Pandas is my jam ),
evaluate the highest diversity factor(s),
make manual “intermediate”-master mixes and give them to the machine for pipetting
Why? Because simple machines are slow. The point of the machine is not to execute the complete preparation of an experiment but to take over the parts that is (what I like to call) “humanly non-executable”. That is the careful addition of hundreds of liquids into their right position in a timely manner.
After this you can still work on making your DoE prep more complicated.
tip reuse → as Rick said: this completely depends on your experiment, if every well contains a completely different liquid composition that you cannot use the same tip for them… but that is never actually the case, because you must have replicates to gather data with any statistical power (≠ statistical significance). In other words >3 wells will have the same liquid composition in any experiment.
Questions:
If you feel comfortable sharing more information, do you have a specific example?
How many factors are you screening in your first experiment?
Are you working with multiple input_master_mixes of different concentrations, i.e. the input_volume is constant, or do you plan to work with one input_mater_mix, i.e. the input_volume changes and is dynamically compensated by water to maintain equal volumes for all experimental_runs/wells overall?
ohh, almost forgot: definitely make use of the powers of a machine that a human doesn’t have:
mutli-dispense: a machine can aspirate volume X and dynamically dispense a fraction of it - e.g. aspirate 210 ul of liquid, dispense 10x 20 ul (don’t forget about the pipette’s retention volume; almost everyone does) - humans have to get a special repeater-pipette to do the same, while a machine can do so out of the box
multi-dispense ‘maximum-effort’: a machine can aspirate voume X and dynamically dispense variable fractions of it - e.g. aspirate 210 ul, dispense [50, 80, 20, 25, 25] ul in different locations
I have never seen a repeater pipette that can do this, and I believe the reason why is because it would be inoperable for a human to calculate all these variable fractions, set the repeater to it, and execute the aspirate-dispense cycles perfectly for hundreds of wells, easy-peasy for a machine - IF the machine has been trained on what correct aspiration/dispensation parameters it needs to use for each (sth that I would think worthy of the term “Liquid class” but that is a different topic)…
y-independent channels: I don’t know your machine, most simpler machines cannot do this, but if you are lucky enough to have one that can: some machines can move their channels/pipettes independently of each other in the y-dimension (as opposed to fixed multi-channel pipettes who cannot).
This means you can dynamically parallelise your aspiration and dispensation as long as the wells in question are in the same y-position (+ some other rules that go beyond this post). Hamilton’s firmware is so well written, it can even do this at the hardware level.
Humans only have one pipetting hand…
There are a lot of other machine super-powers, some of which we have been developing here in PLR (e.g. force-based object detection and expanding on capacitative object detection) but to get stuff done as soon as possible I wouldn’t worry about any of these extras - except for the 3 points given above
@CamilloMoschner@rickwierenga Thanks both, I’ll need to digest this a bit but it sounds sensible. Thanks for the thesis link as well (470Mb! when I wrote mine my storage problems were solved when someone gave me a secondhand 20Mb hard disk - admittedly this was a while ago)
Will get back to you when I have a bit more detail.
haha don’t be too intimidated by the file size of the thesis… I made all my figures myself and am quite picky with figure/graph quality, hence everything is very high resolution and takes up quite a bit of space
)
),
