feat: Add back calibrateToBottom in current releases

[pbeaucage]

Overview

This is related to the now-closed #9674 which I believe was closed in error.

It is extremely difficult to precisely calibrate (within 100um) of the bottom of a labware well without physically moving the tip there during the stock calibration step. For many non-conventional protocols, this is a very important feature; for example:

1. if one wishes to remove the last 50 uL or more or liquid from the well bottom,
2. depositing by spotting onto a plate,
3. avoiding bugs where the z-axis of the pipette will go too far into the labware in z, ram the tip into the labware, and fail to pick up liquid.

Fortunately, a user requested a feature in 3.x and 4.x releases - a bool flag that would change the labware calibration position to the well bottom rather than the top. Specifically, the calibration flow would start at the well top and then expect the user to move the tip to the bottom using z-axis jog before saving position. By precisely doing this calibration the user was essentially guaranteed to have a precise well bottom position within 0.1 mm. As described by @mcous in #9674 this feature didn't make it into 5.x but was considered for re-implementation based on another user's use case there. However, it appears that this never happened.

Could this be added back? It is critical to my OT2 workflow.

Implementation details

An acceptable workaround would be some explicit documentation of the current calibration flow; i.e, "you are at what I think is the top; the nominal height of this labware well is x mm" so that the user can manually jog down x mm, fix the position, and then jog back up x mm to save.

From a UI perspective, a hidden button that simply saved the current position as well bottom rather than top would be a nice, simple tweak. Internally this could just do the (calibration_location) = (current_location) + (labware_height) math before saving and thus this feature might be very quick to implement.

Design

No response

Acceptance criteria

No response

[SyntaxColoring]

I generally agree with you, but one note about this point:

3. avoiding bugs where the z-axis of the pipette will go too far into the labware in z, ram the tip into the labware, and fail to pick up liquid.

If this is happening, it often means the labware definition doesn't exactly match the labware that's physically loaded into the robot. A "calibrate to bottom" option was never really a good fix for that, and in some cases it could be harmfully confusing. If you use "calibrate to bottom" to fix the robot's idea of where bottom of the well is, you'll end up messing up the robot's idea of where the top of the well is. That might sound acceptable if your protocol never does sensitive pipetting relative to the top of the well. But it will also affect the pipettes' minimum safe travel height, which can be a bit dangerous.

[pbeaucage]

This is a really good point!

It's a different feature, but I wonder if a visual or other warning would be warranted it the labware calibration offset goes over a certain magnitude. (conceptually, the offset between the computed minimum safe travel height and the actual traversed height).

In some sense this is just a question of how precise the calibration is and how precise the original definition is. If it's off by 500 um that matters a ton for point 3 above, but probably doesn't create much risk of a travel height crash. There's also a bit of a challenge with the underlying labware data; macroscopic labware height is fairly easy to measure, but I pretty much treat any user measurement of well depth as being ± 1 mm -- including my own.

[mcous]

Thanks for the feedback @pbeaucage! Unfortunately, after internal discussion, we ended up choosing not to focus on getting "calibrate to well bottom" back into the app. However, we have much better workarounds available these days that I would suggest you look into!

In the latest version of the app, the labware check UI will show you what the applied offset will be as you're jogging:

This information, combined with the known depth of the well, might be able to get you to where you need to be. A couple ideas (that both probably require some careful trial and error):

1. Use the app UI to jog to the bottom center of the well, then manually jog back up by the known well depth, and save that offset
2. Use the app UI to jog to the bottom center of the well, write down that vector, and then hardcode the offset with the well height taken into account into your protocol directly via Labware.set_offset
   • Note: as of API level 2.13, using Labware.set_offset is mutually exclusive with using Labware Position Check to set offsets for the same run. We do not guarantee behavior if both are used on the same run
   • TL;DR: if you use Labware.set_offset, you should skip LPC if running protocols through the app

[Koeng101]

i'll just leave this here...

[Koeng101]

@jerader

Just opening this one back up with people who seem to be working on the repository

[skyewindsor]

Hi @Koeng101 , thank you for reopening this issue. We’d like to learn more about how you’re using calibrateToBottom in your lab. Could you email us at product@opentrons.com to schedule a 30-minute call?

Our team made the decision to remove calibrateToBottom because it proved to be less accurate compared to calibrating to the top of the well, for several key reasons:

• It’s harder to determine when the tip is touching the bottom of the well than when it’s aligned with the top.
• The elasticity of the tip can cause overjogging, leading to the tip being pressed too far, which reduces accuracy for that check and any subsequent ones.
• In V- or U-bottom wells, the tip may bend or rotate, complicating X and Y-axis calibration and further affecting precision.
• Manual adjustments to check if the tip is pressed into the bottom can cause the tip to come off the nozzle, diminishing the accuracy of following checks.

While the feature had benefits for experienced users, these challenges ultimately led to its removal. Our goal is to continually improve our tools to better serve scientists like you, and we’d appreciate your insights to help us do that. We look forward to hearing from you.