Opentrons OT-2 pipette tip pickup problem, can't pick up second column from tiprack

Opentrons
1

Hi!
I am using the Opentrons OT-2, with a P20 GEN2 and a P300 GEN-2 multi-channel pipette, and I have an issue with the P300. After calibration, I am trying to run a protocol requiring changing the tips. The pipette P300 picks up the first column of tips without a problem, but for the second line, it doesn’t go deep enough, simply hovering over the rack and the continuing the rest of the protocol without the tips. This problem seem to persist after multiple rounds of calibration. Is there a way to calibrate for other columns of the tiprack and not just the first?
I am wondering if anybody has experienced this problem before. I only found this github issue describing a pretty similar problem: Opentrons/opentrons/issues/934 but it was closed due to that it was caused by an user script error.

Thanks in advance!

1 Like
2

Mind sharing your python script here? It might help elucidate the answer to this puzzle

3

Hello,

Please feel free to email support@opentrons.com which will enable our technical support team to assist as needed. This will ensure proper documentation of any issue and a faster resolution.

Thanks!

4

The script is available on GitHub, under my account

TakacsBertalan/Opentrons-protocols

the protocol name is

magnet_rack_test_300left

(Since apparently linking my own GitHub is spamming…)

1 Like
5

Your script looks sensible to me. You’re using standard opentrons tips I assume right?

I’ve had issues before with the first column picking up but the second and third didn’t work, because the calibration offset was wrong for whatever reason.

Not to sound too tech support-y, but just sanity check that your p300 pipette is calibrated right above the tip rack in A1. If you’re on opentrons version 6+, then you need to calibrate each tiprack individually

Then I’d make a script that just loops through a tip rack on the slot you’re suspect of like this:

for _ in range(12):
p300.pick_up_tip()
p300.return_tip()

Check the API while you’re at it

I know you can change the number of presses and the increment of each press to establish a good seal, maybe you could play with that?

1 Like
6

Thanks for the answer! Yes, we use standard tips that came with the machine.
I wrote a script as you suggested, and weirdly enough, it worked! See the same repository for the script
Both pipettes could pick up the tips from the first 6 columns of the racks without problems. The racks were in the same position (3 and 10 for P300 and P20 respectively) as for the previous script. So this doesn’t seem like a deck calibration problem?
I was suspecting that maybe my offsets (target.bottom(z=3)) or the magnetic rack engaging-disengagig upset the pipette, so I removed those from the previous testing script, but unfortunately it didn’t change the result.

7

I just tried running your script on my device (albiet I have no mag deck, and I had to change the protocol api to 2.10 because I don’t keep with the latest software updates for OT) but mine seemed to behave as expected

Try changing the api to 2.10? :person_shrugging: he seemed to pick up tips fine for me

This problem seem to persist after multiple rounds of calibration

You’re sure you did labware calibrations and not just tiprack calibration right? So you see numbers under your labware within the protocol setup?

8

Thank you for the suggestions! I changed the api to 2.10, and got the same result, unfortunately.
Yes, every time I do the pipette calibrations, I do the labware calibrations as well.
Since your comment, I also recalibrated the deck and the pipettes, but I still get the same result. Tried different tip racks from the same type, again, same result.
I am running out of ideas.

9

Damn sounds really annoying, I can imagine you’re quite frustrated. Maybe post a video if you have one? And definitely ask opentrons support

10

I don’t use Opentrons but is it possible that you have a corrupted definition or file somewhere?

11

I do not think this would be related to /934 as that is from 2018, and the calibration system has been overhauled since then, as well as the entire system has been improved.

I would be curious if the pipette is crashing into the bottom of the wells during the transfer step to the target plate. I do not recall the exact homing sequence off the top of my head, but if the pipette crashed into the bottom of the well and did not home before trying to pick up the next column of tips, it would be off in the z-height by a few mm. This is because the OT-2 does not have encoders to understand when the motor stalls. Other than that, I would ensure that the physical labware matches the labware you have defined in the protocol and that it is sitting correctly on the deck.

2 Likes
12

Thanks for the suggestion! This would make sense, I think the tips crash into the bottom of the liquid reservoir (or at least touch the bottom). I will test adding a few millimeters in the z dimension and report back if it solved the problem.

1 Like
13

Thanks again for the suggestion, this seems to have fixed the problem

1 Like
14

That is great to hear! Happy to help and glad that my suggestion resolved the issue.

1 Like
15

Oh nice to hear! If you have a problem like this in the future maybe it’d be useful to run the program without labware and just a tiprack to see if that was the problem or not

1 Like