fix(api): dont move gen1s all the way up

[sfoster1]

Gen1 pipettes need more z margin than usual when moving around at maximum z for some reason.

testing

• run through dtwiz with a gen1 of any kind

Closes RQA-3229

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.43%. Comparing base (a0f42de) to head (ba419b0).
Report is 50 commits behind head on edge.

Additional details and impacted files

@@             Coverage Diff             @@
##             edge   #16316       +/-   ##
===========================================
+ Coverage   73.62%   92.43%   +18.80%     
===========================================
  Files          41       77       +36     
  Lines        2992     1283     -1709     
===========================================
- Hits         2203     1186     -1017     
+ Misses        789       97      -692     

Flag	Coverage Δ
g-code-testing	92.43% <ø> (?)
shared-data	?

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

see 118 files with indirect coverage changes

[nusrat813]

Tested with gen1 p300s

[SyntaxColoring]

Odd. Do we know why this is only a problem for moveToAddressableArea? That can't be the only place we're traveling at max height, can it?

Is this also going to reduce the effective maximum labware height by 5 mm? Is there a chance that this will break existing protocols?

Looks good to merge as a quick fix if testing says it works and you're comfortable with the caveats above.

[sfoster1]

Odd. Do we know why this is only a problem for moveToAddressableArea? That can't be the only place we're traveling at max height, can it?

I think it is - everywhere else we rely on the baseline arc style move that will hold whatever z it's at or some margin over the tallest loaded labware, whichever is higher. I think that the z position for a gen1 after home has a larger backoff distance than 1mm.

Is this also going to reduce the effective maximum labware height by 5 mm? Is there a chance that this will break existing protocols?

It won't, because as far as I can tell the only place that this kind of motion is used is when you create a moveToAddressableArea with stayAtHighestPossibleZ=True, which isn't done anywhere but by the app during drop tip wiz - based on a grep, anyway.

Looks good to merge as a quick fix if testing says it works and you're comfortable with the caveats above.

Testing does say it works and as far as I can see the caveats don't apply. The change will only affect moveToAddressibleArea commands with stayAtHighestPossibleZ=True, nothing else, and that's only used by dtwiz.