Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bug: Single-Channel pipettes can't calibrate labware at the back of the deck #6886

Closed
SyntaxColoring opened this issue Oct 29, 2020 · 2 comments · Fixed by #7140
Closed

bug: Single-Channel pipettes can't calibrate labware at the back of the deck #6886

SyntaxColoring opened this issue Oct 29, 2020 · 2 comments · Fixed by #7140
Labels
bug hmg hardware, motion, and geometry workaround available This issue has a workaround available, though it isn't necessarily totally fixed.

Comments

@SyntaxColoring
Copy link
Contributor

SyntaxColoring commented Oct 29, 2020 •
edited
Loading

Overview

Two intertwined problems:

  1. Under certain circumstances, during labware calibration, the software will prevent you from jogging the pipette far enough to center it over well A1.
  2. In a subset of those circumstances, you additionally won't be able to jog the pipette at all when calibrating that labware.

Steps to reproduce

  1. Attach a P20 Single-Channel. (We don't think it matters which mount, but I tested with the right.)
  2. Upload this protocol, and do pipette and labware calibration. 
    metadata = {'apiLevel': `2.8`}
def run(protocol):
tip_rack = protocol.load_labware('opentrons_96_tiprack_20ul', 10)
pipette = protocol.load_instrument('p20_single_gen2', mount='right', tip_racks=[tip_rack])
pipette.pick_up_tip()
pipette.return_tip()
  3. When calibrating the tip rack, try to jog around. You may or may not be able to.
    1. If you can jog around, try 0.1 mm jogging as far back as possible, to see how far you could get, if you had to. Note the distance from there to the center of A1—this is how much margin you'd have for an imperfect pipette calibration and imperfect labware (and maybe an imperfect deck calibration?). You may not even be able to reach the center of well A1 at all.
    2. If you can't jog around...
      1. Switch the step size to 10 mm.
      2. Jog one step towards the front of the robot. The pipette should move.
      3. You should now be able to jog around as normal.
      4. Switch the step size to 0.1 mm or 1 mm.
      5. Jog as far back as possible, to see how far you could get, as in step 3i, above.

Tested on v3.21.2.

Current behavior

  • During labware calibration, the software blocks you from jogging a Single-Channel pipette far back enough to comfortably center it over well A1 in an Opentrons tip rack in slots 10 or 11.
  • Additionally, if the initial labware calibration position happens to be beyond that threshold, none of the jog buttons will work. But you may be able to break the robot out with a 10 mm jog towards the front of the robot.

This seems to be an unfortunate result of the OT-2 helpfully preventing you from jogging out-of-bounds.

From journalctl:

Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]: ERROR:    Out of bounds jog
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]: Traceback (most recent call last):
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/site-packages/opentrons/api/calibration.py", line 243, in jog
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/site-packages/opentrons/hardware_control/adapters.py", line 56, in call_coroutine_sync
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/concurrent/futures/_base.py", line 432, in result
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/site-packages/opentrons/hardware_control/api.py", line 959, in move_rel
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/site-packages/opentrons/hardware_control/api.py", line 1093, in _move
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]:   File "usr/lib/python3.7/site-packages/opentrons/hardware_control/util.py", line 93, in check_motion_bounds
Oct 29 16:08:45 OT2CEP20190716A09 uvicorn[231]: opentrons.hardware_control.types.OutOfBoundsMove: OutOfBoundsMove: Out of bounds move: Y=(351.70263198060184 motor controller, 347.93368503257585 deck) too high for limit 350.0

With a P20 Single-Channel, well A1 of a tip rack in slot 10 happens to be very close to those bounds—or maybe actually, truly beyond them.

Expected behavior

  • Single-Channel pipettes should be able to comfortably reach well A1 of all standard labware, even when the labware is in the back row.
    • If this is impossible because the pipette really can't be allowed to move that far back...
      • The initial calibration position should be clamped to what is allowed.
      • You should be able to jog around freely from the initial calibration position, except when that jog would move the pipette of bounds.

See also
@SyntaxColoring SyntaxColoring added bug workaround available This issue has a workaround available, though it isn't necessarily totally fixed. hmg hardware, motion, and geometry labels Oct 29, 2020
@SyntaxColoring
Copy link
Contributor Author

SyntaxColoring commented Oct 29, 2020 •
edited
Loading

Workarounds

Try any of these:

  • Switch the step size to 10 mm. Then, jog the pipette towards the front of the robot. Then, decrease the step size to 1 mm or 0.1 mm. From there, you should be able to jog around normally. But the distance that you can jog towards the back of the robot will be limited.
  • Move your tip rack to a different deck slot, somewhere other than the back row.
  • Downgrade under robot software v3.21.0 (Opentrons Support can help you with this).

@SyntaxColoring
Copy link
Contributor Author

SyntaxColoring commented Oct 29, 2020 •
edited
Loading

The gantry does have several mm of extra physical space to jog back, but it's nontrivial for the software to let you use it. Some notes from @sfoster1 on why:

Well there's the extra annoying thing that the cross gantry can travel farther +y when the head is -x than it can when the head is at its x stop, and in fact can physically go farther +y than its home position when the gantry is in those other positions. but this really really is not a safe thing to do

[For the software to permit jogging that far +y when the head is -x,] we would have to implement a bunch of special case behavior for homing in that situation, and probably carving out a notch in the total area of the gantry for when it would actually trigger the stops

@SyntaxColoring SyntaxColoring changed the title bug: Labware calibration jog buttons do nothing when close to the back of the deck bug: Single-Channel pipettes can't calibrate labware at the back of the deck Oct 29, 2020
sfoster1 added a commit that referenced this issue Dec 17, 2020
@sfoster1
fix(api): bump y max bounds to match robot geometry
8de9359 
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 sfoster1 mentioned this issue Dec 17, 2020
Merged
sfoster1 added a commit that referenced this issue Jan 4, 2021
@sfoster1
fix(api): bump y max bounds to match robot geometry
ce1f360 
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 added a commit that referenced this issue Jan 4, 2021
@sfoster1
fix(api): bump y max bounds to match robot geometry (#7140)
85b3d6b 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug hmg hardware, motion, and geometry workaround available This issue has a workaround available, though it isn't necessarily totally fixed.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(api): bump y max bounds to match robot geometry Opentrons/opentrons
1 participant
@SyntaxColoring