Robot does not keep a consistent 'top of tube' definition in 5.0+

[kelleyjbrady]

Overview

On OT software&robot v5.0+, freshly calibrated (deck and all pipette parameters) before the run: Run a dispensing protocol where, in my case, a p300_single_gen2 aspirates from a mother tube, then dispenses into a/some daughter tube(s).

Current behavior

Robot moves into position to perform the first aspiration -- moving to the mother tube with sufficient height under the currently loaded tip such that the tip does not collide with the outside of the mother tube (ie. it comes in over the tube, then goes down into it). The robot then aspirates from the tube, but as it attempts to move to the daughter tube it does not raise the tip to a sufficient height to prevent the tip from colliding with the inside wall of the mother tube (even though the protocol presumably 'knows' how tall the tube is or the tip would have collided with the outside of the tip as the robot got into position to aspirate). If you do not put the mother tube into the rack at the start of the process and let the robot run as if it had aspirated, then dispensed and then, without getting your hand stabbed, you quickly load a mother tube onto the rack, it will crash the tip into the outside wall of the tube when it attempts to move back to perform the next mother tube aspiration (even thought it was able to do exactly such a move in the very first step).

Expected behavior

The robot should not collide with properly calibrated tubes. Downgrading to 4.6.2 resolves the issue.

[mcous]

Thanks for the report! Which tube rack definition are you observing this behavior with? A short protocol that reproduces this behavior would also be useful.

[kelleyjbrady]

The mother rack is a opentrons_24_tuberack_eppendorf_1.5ml_safelock_snapcap, the daughter is a opentrons_96_aluminumblock_generic_pcr_strip_200ul sitting on a temperature module gen2. Unfortunately I need all of my robots functioning, so I will not be able to re-upgrade to 5.0 or 5.0.1 in order to reproduce the error, but I will make a toy version of the protocol in question tomorrow morning -- sorry I'm on PST and need to get home for the day.

[UfieA]

Hi Kelley, we observed the same issue at our two systems at two different locations, and no success by downgrading to 5.0.1 to 5.0.0 to 4.7.0 but you mentioned downgrading to 4.6.2 resolves the issue? We can't run either jason or py generated profiles, it simply does not save the offsets for the labware. You see this if you switch from one profile to other and also if you turn off the OT-2 or logout of the computer.

[mcous]

There have been no (intentional) changes to motion planning or labware definitions in the 5.x release. In terms of actual protocol logic, the primary change is that 5.x sources a labware's offset vector from the Labware Position Check wizard, whereas 4.x sourced that offset vector from the old "labware calibration" flow, which saved offsets to disk by labware definition.

I think the most likely scenario here is that the persisted offset values you were using in 4.x had been entered to account for some other issue, and moving to 5.x and having to re-do the offset measurement exposed that issue again. Issues that could cause this:

• As of yet unknown error with that tuberack definition
• As of yet unknown motion planning bug
• Incorrect tip length calibration
• Incorrect deck calibration

As a starting point, I would compare the offset vector you have saved in 4.x with the measured offset vector from Labware Position Check in 5.x

[mcous]

@UfieA please contact Opentrons support, they are better equipped to handle your issue than this bug tracker. After you downgrade the Opentrons App to 4.7, you must subsequently downgrade the OT-2 software, too from the robot's settings page. If you do not downgrade both your app and robot software, you won't be able to open and run protocols.

You can also disable the app's update notifications, which I would recommend in a clinical setting.

I'm going to hide your GitHub comment above since it's off topic from this original issue about tube-rack movement issues. Please feel free to continue this discussion in #9603.