OT-2 moving the pipette along the z axis and pipetting the same time - Is it possible?

This is half a question and half a suggestion for the future I guess, because I suspect that the answer is no.

Working with larger amounts of liquids (180-200 uL ethanol in this case) and 96 well PCR plates has shown us the following problem: when the pipette tip is set to dispense at the bottom of the well, the liquid will overflow, because of the cumulative volume of the liquid and the pipette tip is greater than the total volume of the well. Currently we are avoiding this by dispensing from the top of the well, but this can lead to some of the liquid sticking to the side of the well. Similarly, when we want to remove large quantities of liquid from the wells, we have to start from the top, but that means that we don’t remove all of the liquids. So we need to split up the process into multiple steps, with different depths.
When manually pipetting, the solution for this problem is simple: start dispensing at the bottom, and raise the tip as the well fills up (or vice versa if removing the liquid from the well).

Would it be possible to do this with the OT-2? If not, would it be feasible to implement in a later API version?

I’ve asked opentrons this before and this is something that allegedly cannot be done: EDIT: On the OT-2, as you mentioned

The workaround you mentioned is the most common; split up your volumes and aspirate / dispense at different z heights, which is basically the same thing.

1 Like

We’re launching liquid level tracking for the Flex later this year. I’ll check to see if it will be available on the OT-2 as well!

1 Like

Sounds cool, thanks for the reply!

It just occured to me that you can also program in some rudimentary liquid level tracking based upon some simple math in python if you know how high the liquid level is at a few points.

You can create a linear equation and plot the predicted height and just tell your pipette to go where the liquid level should be (or 2ish-mm below to be safe). Takes some more work but I’ve done it before with an OT-2 and 50mL conical tubes


If you are interested in controlling your OT-2 using PyLabRobot then you can already do so since I added calculate_height_by_volume functions in pull request #139 :slight_smile:

These functions can calculate liquid height very precisely … If people add the necessary information for their labware


we don’t support movement along the z-axis during aspiration/dispense currently on OT. Not sure if this is exposed through the OT HTTP api at all, but should be a super easy add if it is supported. After that, thanks to Camillo, z-following should be super easy

Sorry, I should have quoted what my response was addressing. I was responding specifically to @Shinedalgarno’s message (and not the question in the thread title):

i.e. with the calculate_height_by_volume function in PyLabRobot (PLR) you can calculate e.g. the height of a liquid being aspirated from a well, before and after the aspiration.
You can then easily tell the OT-2 to move the tip end 2 mm below the end_height, and aspirate from there. That way you will not enter the tip too far into the well but have the tip immersed until the end of the aspiration.
This is very useful for Opentrons tuberacks, e.g. with a 50ml Falkon you would drown your pipette if you aspirated from the bottom and have >30ml liquid in the tube.

But I am not sure PLR could support liquid level following during aspiration/dispensation:
If I understand the OT-2 control system correctly it has to execute one firmware command at a time, i.e. parallelisation of the z-drive and the pipette piston drive is not firmware-supported at the moment?

1 Like

The OT-2 can only handle one API command at a time, so you cannot move and aspirate/dispense simultaneously. You might be able to do it if you communicated with the OT-2 at a lower level, such as G-code, but it would likely be unstable and require a fair amount of work to figure out.

1 Like

Do you have any plans to expose this through the api? Would be very useful!


I no longer work at Opentrons, but if I had to guess, they would not soon expose this type of communication via the API. Agree it would be helpful!