fix(shared-data): evotips v1 are schema 2 now

[sfoster1]

We had the evotips labware and adapter as schema 3 labware. This was probably necessary while this was a 3-element stack, but now it is not, and we need to avoid shipping schema 3 labware in 8.3 so that we retain the ability to change it.

Closes EXEC-1179

review

• seem fine?

testing

• smoke test. nothing checks schema identity, just whether data is there, and all the data that the code in 8.3 uses is still there.

[github-actions]

A PR has been opened to address analyses snapshot changes. Please review the changes here: #17430

[SyntaxColoring]

There's a shared-data test failing now because the tips (wells[*].z + wells[*].depth) are higher than the bounding box (dimensions.z).

That test should have prevented the definition from being written like this in the first place, but it did not run on the schema 3 files. That was probably accidental, similar to #17425, and we can fix the test in a separate PR. EXEC-1193

But I'm not sure how the definition should be fixed here. The documented intent of dimensions is that it's the outer bounding box of the whole labware, which implies to me that it should envelop the tips, even if the tips extend beyond the "main body" of the labware. Can we just...do that, or is the existing zDimension value load-bearing?

@CaseyBatten @Laura-Danielle?

[CaseyBatten]

There's a shared-data test failing now because the tips (wells[*].z + wells[*].depth) are higher than the bounding box (dimensions.z).

That test should have prevented the definition from being written like this in the first place, but it did not run on the schema 3 files. That was probably accidental, similar to #17425, and we can fix the test in a separate PR.

But I'm not sure how the definition should be fixed here. The documented intent of dimensions is that it's the outer bounding box of the whole labware, which implies to me that it should envelop the tips, even if the tips extend beyond the "main body" of the labware. Can we just...do that, or is the existing zDimension value load-bearing?

@CaseyBatten @Laura-Danielle?

I believe we can and probably should continue our pattern of the Z dimension representing the whole "naive block" of a labware's geometry, with the tips included "inside" that block, however I believe we will need to increase the stackingOffsetWithLabware values to reflect that new overall height. I think we probably want to remeasure the evotip length to double check accuracy, and then set the overall labware height to match that. At that point, we subtract the difference in height from the bottom of the metal component of the labware to the top of the evotips, and account for that difference in the stackingOffsetWithLabware values for the evotip adapter (96ch) and the deep well plate (8ch).

[sfoster1]

Okay, turns out we don't need to change the stack offsets because the thing that would make us do that is changing the implied bottom location or changing the adapter geometry, neither of which we did. So, all good!

[CaseyBatten]

Looks good and should be good to go, some optional comments on the labware load on some of our test fixtures.

[CaseyBatten]

Since we're no longer doing the V3 version of this labware we can probably stop referring to it by the entire load name and can just use the shared_data labware load_definition function with something like:

return LabwareDefinition.parse_obj(
        load_definition("evotips_opentrons_96_labware", 1)
)

This would mean when we update the whole system to use V3 definitions as the default the test cases will start using those by default as well.

[CaseyBatten]

Ditto here

[CaseyBatten]

And here as well on this test.

[sfoster1]

good point

[sfoster1]

I'll switch it to work like the other PE fixtures which loads from shared data python bindings but still specifies version

[SyntaxColoring]

LGTM if you two are satisfied with the stack offset / zDimension thing. Thank you!