fix(shared-data): Sync dimensions and spacing to latest hardware values #19127

SyntaxColoring · 2025-08-05T19:42:26Z

Overview

Changelog

Copies the numbers from the "XY Spacing" tab of the Google Sheet linked in EXEC-1480.

This means updating the coarse-grained labware and well dimensions, but not the fine-grained innerWellGeometry. innerWellGeometry should have already been sorted out by fix(shared-data): Sync innerLabwareGeometry to latest hardware values #18266.
- This was partially script-assisted, but only partially. The details are in the commit messages.
- Unfortunately, I couldn't bring the tube racks fully up to date because the spreadsheet is missing some details. It tells us tube depths, but it doesn't tell us anything about where the tube sits vertically. So if we need to fix the depth, we have no way of knowing whether to grow/shrink it from the top or the bottom.
Adjust our labware definition tests to only check each labware's latest version for sensible geometry.

Test Plan and Hands on Testing

Relying on code review and automated labware definition sanity checks to catch any flagrant errors.

Review requests

For reviewability, this is broken up so you can go commit-by-commit to see what actually changed. The consolidated diff is not helpful because it just looks like a million new files.

Basically just double-check my new numbers against the numbers in the Google Sheet and make sure I didn't make any silly mistakes like copying from the wrong place.

Risk assessment

Low. Most of the changes are pretty small, numerically.

…ometry.

…dsheet, via script. Notes: - Run import_dimensions_from_hw.py. - Manually fix up the output to reduce the diff. e.g. undo changes like 0->0.0. - Opentrons tube rack labware like opentrons_24_tuberack_generic_2ml_screwcap are incomplete in the spreadsheet and couldn't be parsed by the script. They need separate manual attention.

x/y were swapped in innerLabwareGeometry.

These "aluminum block + tube" labware are not mentioned in the hardware spreadsheet. But, they have the same tubes as some "tube rack + tube" labware, which means we can take the diameters from there. * opentrons_24_tuberack_nest_0.5ml_screwcap <- opentrons_24_tuberack_nest_0.5ml_screwcap * opentrons_24_aluminumblock_nest_1.5ml_screwcap <- opentrons_24_tuberack_nest_1.5ml_screwcap * opentrons_24_aluminumblock_nest_1.5ml_snapcap <- opentrons_24_tuberack_nest_1.5ml_snapcap * opentrons_24_aluminumblock_nest_2ml_screwcap <- opentrons_24_tuberack_nest_2ml_screwcap * opentrons_24_aluminumblock_nest_2ml_snapcap <- opentrons_24_tuberack_nest_2ml_snapcap This also makes each definition's tube diameter internally consistent with the diameter implied by its innerLabwareGeometry, yay.

New numbers based on the drawing "SINGLE WELL RESERVOIR SUPPORT DWG" rev A1.0. xDimension 108->108.7: The old value matched the bottom of the well, but a well's xDimension needs to represent the top of the well. 108.7 matches the drawing and the number in innerLabwareGeometry. yDimension 72->70.7: I'm not sure where 72 came from, but 70.7 matches the drawing and the number in innerLabwareGeometry.

We can't easily use a script for this because the spreadsheet doesn't have full information for these definitions--it only has the diameters and depths. Also, some of the tube racks are heterogeneous. Also, we can only copy over the diameter values, not the depth values. Since the hardware spreadsheet doesn't give us a known tube top position, we can't know whether to grow/shrink the tube depths from the bottom or the top.

The hardware spreadsheet doesn't explicitly mention the diameter of these tubes, so this is a little bit dicey. These new numbers make the well diameter internally consistent with the definition's innerLabwareGeometry. A while ago, in PR #17082, this same 27.95 -> 28.18 change was made to opentrons_10_tuberack_nest_4x50ml_6x15ml_conical, which shares the same tubes. I'm guessing this definition was just accidentally omitted.

@rclarke0

I've asked @rclarke0 and @HovanNgoOpentrons about these. They'll probably get fixed in a separate PR.

SyntaxColoring · 2025-08-05T19:44:13Z

shared-data/js/__tests__/labwareDefSchemaV2.test.ts

+      const labwareWithXYDimensionMismatches = [
+        // todo(mm, 2025-08-05): Investigate and resolve these mismatches.
+        'eppendorf_96_wellplate_1000ul',
+        'nest_8_reservoir_22ml',
+      ]
+
+      if (
+        labwareWithXYDimensionMismatches.includes(
+          labwareDef.parameters.loadName
        )
      ) {
-        expect(wellDepth).not.toStrictEqual(topFrustumHeight)
+        expect(xyDimensionsFromWell).not.toStrictEqual(xyDimensionsFromGeometry)
      } else {
-        expect(wellDepth).toStrictEqual(topFrustumHeight)
+        expect(xyDimensionsFromWell).toStrictEqual(xyDimensionsFromGeometry)
      }


@rclarke0 FYI here's where I ended up with this test. It's currently missing the handling that you wrote for circular sections, but if you end up keeping that, I'll merge it in here somehow.

codecov · 2025-08-05T19:46:39Z

Codecov Report

❌ Patch coverage is 0% with 54 lines in your changes missing coverage. Please review.
✅ Project coverage is 25.46%. Comparing base (c8d5916) to head (5682cda).
⚠️ Report is 35 commits behind head on edge.

Files with missing lines	Patch %	Lines
...p/src/organisms/ODD/QuickTransferFlow/constants.ts	0.00%	54 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #19127      +/-   ##
==========================================
+ Coverage   24.24%   25.46%   +1.22%     
==========================================
  Files        3370     3371       +1     
  Lines      296410   294532    -1878     
  Branches    37690    37678      -12     
==========================================
+ Hits        71868    75017    +3149     
+ Misses     224518   219486    -5032     
- Partials       24       29       +5

Flag	Coverage Δ
protocol-designer	`18.93% <0.00%> (-0.02%)`	⬇️
step-generation	`5.37% <0.00%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...p/src/organisms/ODD/QuickTransferFlow/constants.ts	`0.00% <0.00%> (ø)`

... and 396 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…sion/yDimension.

rclarke0

Left comments on files where I saw discrepancies

rclarke0 · 2025-08-06T21:21:01Z

shared-data/labware/definitions/2/agilent_1_reservoir_290ml/4.json

+      "yDimension": 71.25,
+      "totalLiquidVolume": 290000,
+      "x": 63.88,
+      "y": 42.74,


the google sheet says 42.73

Probably the same thing as #19127 (comment).

rclarke0 · 2025-08-06T21:31:01Z

shared-data/labware/definitions/2/corning_24_wellplate_3.4ml_flat/5.json

+      "diameter": 16.256,
+      "totalLiquidVolume": 3400,
+      "x": 113.96,
+      "y": 13.79,


the sheet says the y offset is 13.78 so I think this should also be 13.78 since its the bottom most well

Probably the same thing as #19127 (comment).

rclarke0 · 2025-08-06T21:33:19Z

shared-data/labware/definitions/2/corning_384_wellplate_112ul_flat/5.json

+      "yDimension": 3.632,
+      "totalLiquidVolume": 112,
+      "x": 115.62,
+      "y": 8.98,


the sheet says the Y offset is 8.99

Probably the same thing as #19127 (comment).

rclarke0 · 2025-08-06T21:36:34Z

shared-data/labware/definitions/2/corning_48_wellplate_1.6ml_flat/6.json

+      "diameter": 11.1,
+      "totalLiquidVolume": 1600,
+      "x": 109.72,
+      "y": 10.12,


y offset is 10.08 on the sheet

This is interesting, thanks for calling this out.

According to the spreadsheet:

y-spacing: 13.08

y-offset: 10.08

y-dimension of overall labware: 85.600

If you treat y-offset as the distance from the front of the labware to the center of the "F" row, then this y value should be 10.08. This is what you're doing.

If you treat y-offset as the offset from the back of the labware to the center of the "A" row, then this y value should be 85.600 - 10.08 - 13.08*5 = 10.12. This is what I did. I did this because, as I understand it, the standard way of dimensioning things like this is from the back-left.

I have to imagine that, physically, Corning intends for the well distribution to be exactly symmetrical, evenly dividing the space across 6 rows. Somewhere along the line—maybe Corning's technical drawings, maybe our spreadsheet—the y-spacing or y-offset is getting rounded, and the space is no longer divided exactly evenly.

So our options are:

Make the y-offset match the spreadsheet in the A-row but not the F-row. (This is what this PR has now.)

Make the y-offset match the spreadsheet in the F-row but not the A-row.

Make the y-offset match the spreadsheet in the A-row and the F-row, but then the y-spacing doesn't match the spreadsheet anymore.

My initial reaction is that I'm 50/50 between option 1 and option 2. I don't think we should do option 3.

OK, after looking at the spreadsheet again, I'm leaning towards option 1, because I think that matches how the spreadsheet is thinking about it. In other words, I'm pretty sure the spreadsheet is thinking of y-offset as a measurement from the back of the labware to the center of the "A" row. Notice how in the "ERROR" section, this labware had an error of -0.040, which is corrected here.

Makes sense, I agree with option 1. I think this formula should get added to the PR description so that its clear why the offset numbers in the sheet aren't directly present in the labware definition. I guess this is still a result of the issue that the labware does not assume the top left corner is (0,0).

rclarke0 · 2025-08-06T21:37:46Z

shared-data/labware/definitions/2/corning_6_wellplate_16.8ml_flat/5.json

+      "diameter": 35.433,
+      "totalLiquidVolume": 16800,
+      "x": 103,
+      "y": 23.19,


y offset is 23.16

Probably the same thing as #19127 (comment).

shared-data/labware/definitions/2/opentrons_24_tuberack_eppendorf_2ml_safelock_snapcap/3.json

shared-data/labware/definitions/2/opentrons_6_tuberack_nest_50ml_conical/3.json

rclarke0 · 2025-08-06T22:07:17Z

shared-data/labware/definitions/2/opentrons_tough_1_reservoir_300ml/2.json

I dont think this needs a 2.json file because it hasn't been released to the public yet

This just happened today, but #19142, which I think is going into v8.6.0, does release it to the public.

(And from speaking with Seth, this PR will not go into v8.6.0, for risk mitigation reasons. So we gotta leave v1 of this labware alone.)

Reminder to self: This is getting fixed in-place in #19126 so it should probably be removed from this PR.

rclarke0 · 2025-08-06T22:08:09Z

shared-data/labware/definitions/2/usascientific_12_reservoir_22ml/4.json

+      "yDimension": 71.88,
+      "totalLiquidVolume": 22000,
+      "x": 14.38,
+      "y": 42.71,


y offset in sheet is 42.76

Probably the same thing as #19127 (comment).

rclarke0 · 2025-08-06T22:08:49Z

shared-data/labware/definitions/2/usascientific_96_wellplate_2.4ml_deep/4.json

+      "yDimension": 8.2,
+      "totalLiquidVolume": 2400,
+      "x": 14.4,
+      "y": 11.3,


y offset on the sheet is 11.2

Probably the same thing as #19127 (comment).

rclarke0

Thanks for explaining the offsets

SyntaxColoring · 2025-08-07T19:04:37Z

Tagging "do not merge": we want to wait until after the v8.6.0 release branch is cut from edge.

SyntaxColoring added 13 commits August 4, 2025 18:07

Limit geometry tests to just the most recent version of each labware.

054a80f

Test xDimension/yDimension/diameter, in addition to depth, against ge…

177a41e

…ometry.

Create drafts from the latest versions of each labware.

99224e7

Manually fix nest_1_reservoir_195ml topXDimension/topYDimension.

eb5a2a4

x/y were swapped in innerLabwareGeometry.

Delete drafts that we didn't change.

0d07671

Copy drafts that we changed to new labware versions.

386c3a7

Remove test xfails for labware that we've just fixed.

fb645e7

Add xfails for new labware.

6f322c3

I've asked @rclarke0 and @HovanNgoOpentrons about these. They'll probably get fixed in a separate PR.

SyntaxColoring requested a review from rclarke0 August 5, 2025 19:42

SyntaxColoring commented Aug 5, 2025

View reviewed changes

SyntaxColoring mentioned this pull request Aug 5, 2025

fix(shared-data): Sync dimensions and spacing to latest hardware values #18284

Closed

SyntaxColoring changed the title ~~fix(shared-data): Correct various labware and well dimensions~~ fix(shared-data): Sync dimensions and spacing to latest hardware values Aug 5, 2025

nest_1_reservoir_195ml: Complete my incomplete fix for swapped xDimen…

40500da

…sion/yDimension.

SyntaxColoring mentioned this pull request Aug 5, 2025

fix(shared-data): ensure agreement between top frustum and well dimensions #19126

Merged

SyntaxColoring marked this pull request as ready for review August 5, 2025 21:08

SyntaxColoring requested review from a team as code owners August 5, 2025 21:08

SyntaxColoring requested review from TamarZanzouri and removed request for a team August 5, 2025 21:08

Update Quick Transfer constants.

5682cda

rclarke0 requested changes Aug 6, 2025

View reviewed changes

rclarke0 self-requested a review August 7, 2025 17:38

rclarke0 approved these changes Aug 7, 2025

View reviewed changes

SyntaxColoring added the DO NOT MERGE Indicates a PR should not be merged, even if there's a shiny green merge button available label Aug 7, 2025

fix(shared-data): Sync dimensions and spacing to latest hardware values #19127

Are you sure you want to change the base?

fix(shared-data): Sync dimensions and spacing to latest hardware values #19127

Uh oh!

Conversation

SyntaxColoring commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Changelog

Test Plan and Hands on Testing

Review requests

Risk assessment

Uh oh!

SyntaxColoring Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

rclarke0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SyntaxColoring Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SyntaxColoring Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rclarke0 left a comment

Choose a reason for hiding this comment

Uh oh!

SyntaxColoring commented Aug 7, 2025

Uh oh!

Uh oh!

SyntaxColoring commented Aug 5, 2025 •

edited

Loading

SyntaxColoring Aug 5, 2025 •

edited

Loading

codecov bot commented Aug 5, 2025 •

edited

Loading

SyntaxColoring Aug 7, 2025 •

edited

Loading

SyntaxColoring Aug 7, 2025 •

edited

Loading