Opentrons: One pipette working other pipette mm off in z axis

[asogluizzo]

[trace-mark]

Voice of the customer here:

Here's what I noticed--my protocol uses both 20µL and 300µL pipettes, but the labware part of the pre-run calibration only ever happens with the 300µL pipette. I changed the data file that drives the dispense volumes so that only the 20µL pipette was required. That forced the OT to calibrate the labware with the 20µL pipette. Now on mixed runs, using both 20µL and 300µL pipettes, it works correctly. This implies that it is using the labware calibrations from the earlier 20µL-only run on subsequent runs.

To me it really should be doing both the 20µL and 300µL labware calibrations on each run. If they are important enough to do for one pipette they are important enough to do for both.

Is the software supposed to calibrate the labware on both pipettes when there are two pipettes used in a protocol? If not, what's the thinking behind that?

As a reproduction scenario, here's what I would suggest. Reset all calibrations on an OT (which I had done prior to this problem happening). Run a protocol that uses both 20uL and 300uL pipettes. Note (I expect) that the pre-run labware calibration is only done with the 300uL pipette. This, I think, is the bug. It should be doing the calibration of the labware with both pipettes, otherwise its using an unknown calibration for the 20uL/labware combination.

[pbeaucage]

Another customer having this issue here. This started in December with the 4.x update.

Here’s what I’ve done over the past few days to reproduce from a clean slate:

Set an OT-2 up with a 300 uL gen 1 pipette on the right mount and a 1000 uL gen 2 on the left. ( it’s probably unlikely that the mix of generations matters, and I’m similarly skeptical that the positions matter, but full disclosure)

Erase calibrations and carefully re-do full calibration flow (deck, pipette, tip length)

Set up deck with tipracks for 300ul and 1000 ul, a deep 96 well plate, and two reservoirs, one full of water with food coloring in it (I find this really helpful to visualize liquid levels and locations easier) and the other empty. In the interest of full disclosure, I use a custom 3d-printed bottle holder here that positions standard 100 ml Nalgene bottles at well defined positions within the deck slot, but a reservoir would be equivalent – it pipettes well above the bottle bottom.

Perform labware calibration using standard flow. As far as I can tell it’ll arbitrarily pick one pipette to calibrate the rest of the labware with after doing the tiprack calibrations with the respective pipette. My robot calibrated with the 1000 uL.

From an API context running on the pi (a custom Flask server, but I think this would be the same in a protocol), transfer 500 uL from a reservoir position to a well, then pick up the 500uL plug back out of the well and dump it in the other reservoir, all using the 1000ul pipette. If the calibrations are correct, this should leave less than a 100 um depth layer in the well (it does on mine, using Nest 1.6 mL round bottom 96-well plates).

Command the same transfer with a volume of 300 uL using the 300 uL pipette. The depth left on the bottom of the well is about 1.5 mm, and the amount picked up on the transfer back to the trash is about 200 uL, leaving about 100 uL in the well, at least on my system with round-bottom deep 96 plates.

If you happen to do the calibration with the 300 uL pipet and not the 1000 uL pipette, this gets really bad. Now, instead of leaving liquid on the well bottom, the robot firmly rams the pipette into the bottom of the well, so firmly that it can’t actually draw up any liquid. It’s the same ~1.5 mm offset, just offset into the plate and not above the plate. I haven’t reproduced this facet since the full system reset, mostly because I needed to get up and running today and running with the 300 disabled is fine for tonight. I am pretty confident the error would occur here too.

I have not tried reproducing this with a protocol uploaded via the app, this is all within the API context in our Flask server.

My thinking, based on what I’ve poked around at in the codebase… three possibilities:
(1) Some difference in how the pipettes are driven between the tip length calibration and the actual run, perhaps different motor power, that’s actually making the tip length different. Unlikely, but would explain it.
(2) a fundamental issue where it needs two sets of labware calibrations and is only generating/using one, or
(3) it’s a gremlin where a protocol context opened locally on the robot doesn’t know where to get all the right configuration files because there’s some difference between the environment when you natively start “python myprogram.py” and when the opentrons robot server runs. This bit me earlier and I fixed it by copying the environment from the systemctl command for the robot server, specifically RUNNING_ON_PI=True and OT_SMOOTHIE_ID=AMA, but there could be other features. Though if Mark is using the standard protocol flow then that would point away from this as the origin.

[emilywools]

hey there, @pbeaucage could you share your calibration logs with us to help troubleshoot? These logs are in the Opentrons App > Robot > calibration section. If you are ok sharing, you can email them to me at [email protected].

[SyntaxColoring]

@Laura-Danielle Correct me if I'm wrong, but I think PR #7417, released in v4.2.0, intended to close this.

However, as I'm writing this, I see some Support discussions of this maybe continuing to happen in v4.2.0, so I guess let's keep this open for now?

[jepdavidson]

Hi, I've just upgraded to 4.2.0 / api 2.9 and am seeing very similar things to the original poster (coincidentally, I have a very similar pipette setup - 1000uL_single gen2 in LEFT, and 300uL_single gen2 in RIGHT).

The 1000uL pipette appears to be set ok - eg touch_tip() commands occur in what appears to be the correct place, with the tip making contact with the inside edge of the wells. However, the 300uL pipette appears to be running higher than expected - volume left in wells after transfers, and touch_tip() commands floating above wells...

Looking at the callibration log, both pipettes seem to have a zero offset in z, so perhaps this setting isn't getting written but I got lucky with the 1mL pipette? I have attached the log here (renamed .json to .txt to allow upload)
opentrons-SD20190612A18-calibration.txt
.

Incidentally, I did wonder whether the tip length calibration settings could be incorrect - but measured them manually and they seem ok for both pipettes.

Any help would be greatly appreciated, as this is definitely stopping us using the robot in production right now!

Kind regards

James

[Laura-Danielle]

Resolved in software version 4.2.1.