fix(api): bump y max bounds to match robot geometry #7140
Conversation
Codecov Report
@@ Coverage Diff @@
## edge #7140 +/- ##
==========================================
+ Coverage 78.96% 78.97% +0.01%
==========================================
Files 265 265
Lines 19015 19027 +12
==========================================
+ Hits 15015 15027 +12
Misses 4000 4000
Continue to review full report at Codecov.
|
|
|
||
| _HOME_POSITION = {'X': 418.0, 'Y': 353.0, 'Z': 218.0, | ||
| _HOME_POSITION: Final = {'X': 418.0, 'Y': 353.0, 'Z': 218.0, | ||
| 'A': 218.0, 'B': 19.0, 'C': 19.0} | ||
|
|
||
| _BOUNDS: Final = {'X': 418.0, 'Y': 370.0, 'Z': 218.0, |
There was a problem hiding this comment.
Doesn't have to happen in this PR, but can we deduplicate these numbers with the ones in driver_3_0.py?
| } | ||
| Y_BOUND_OVERRIDE: Final = 370 |
There was a problem hiding this comment.
Can we leave a comment briefly explaining what this is and why we need it (as you've done in the PR description)?
| from typing_extensions import Final | ||
|
|
||
|
|
||
| HOMED_POSITION: Final = { |
There was a problem hiding this comment.
Just FYI, we might want to check these numbers. Most of these match nominal home of my OT-2, but not all of them...
There was a problem hiding this comment.
There's a bunch of weirdness going on with these, and in the actual running smoothie driver they get updated from the results of doing the actual home(). I hate all of this.
We now helpfully check that jogs don't overlap the maximum motion range of each axis, at least in the positive direction, using the home positions. This works pretty well for Z and X since it straightforwardly prevents hard limit errors from unintentional endstop triggers, which happen at the home position as one might expect. Unfortunately, the robot geometry makes this approach completely invalid for Y. When homing, the Y endstop (which is located on the back of the head) actually interacts with a post projecting from the back of the robot, which is located on the right side of the robot. This is the reason we must always home X before homing Y: to make sure the head is in the correct position for the Y endstop to interact with the post. If the head is _not_ all the way to the right, it can actually go much farther back - past the home location, past where the switch would interact with the post. And the deck layout is designed to take advantage of this; the position that A1 of most labware lives in is farther back than the post, and thus customers would get spurious jog failures when calibrating labwares in slots 10 and 11 using single channel pipettes (because multi channels are wider in Y, the gantry doesn't go far enough back to trigger the issue). The fix is to create a different bound in the Y. Closes #6886
sfoster1
force-pushed
the
api_fix-y-max-bounds
branch
from
19b2b1b to
b4721ea
Compare
We now helpfully check that jogs don't overlap the maximum motion range
of each axis, at least in the positive direction, using the home
positions. This works pretty well for Z and X since it straightforwardly
prevents hard limit errors from unintentional endstop triggers, which
happen at the home position as one might expect.
Unfortunately, the robot geometry makes this approach completely invalid
for Y. When homing, the Y endstop (which is located on the back of the
head) actually interacts with a post projecting from the back of the
robot, which is located on the right side of the robot. This is the
reason we must always home X before homing Y: to make sure the head is
in the correct position for the Y endstop to interact with the post.
If the head is not all the way to the right, it can actually go much
farther back - past the home location, past where the switch would
interact with the post. And the deck layout is designed to take
advantage of this; the position that A1 of most labware lives in is
farther back than the post, and thus customers would get spurious jog
failures when calibrating labwares in slots 10 and 11 using single
channel pipettes (because multi channels are wider in Y, the gantry
doesn't go far enough back to trigger the issue).
The fix is to create a different bound in the Y.
Closes #6886
Risk
Low, only happens during jog during labware calibration and widens the bound
Testing
Put a labware in slot 10 or 11 and try to calibrate it using a single channel. You should be able to jog freely.