Opentrons: Robot is not able to pick up tips in Protocol Designer protocols with multiple tipracks

Created on 14 Nov 2019  路  3Comments  路  Source: Opentrons/opentrons

Overview

Per Issue #4288 this behavior still exists in protocols created in Protocol Designer.

Steps to Reproduce

  1. Upload one_tiprack_test.json file to your OT-2
  2. Calibrate the pipette, tiprack, and labware
  3. Run the protocol. The robot is able to successfully pick up all the tips in the first column
  4. Upload four_tiprack_test.json file to your OT-2
  5. Calibrate the pipette, all four tipracks, and labware
  6. Run the protocol. When the robot moves to pick up the first column of tips it completely misses.

one_tiprack_test.json.zip

four_tiprack_test.json.zip

api bug

Most helpful comment

Marking this as API b/c all PD can do is save a valid JSON - these protocols are specifying the intended behavior eg four_tiprack_test.json pickUpTip commands specify: "pick up tips from column 1-12 in slot 2, then same for slot 3, then slot 10"

This needs to be addressed in the JSON executors or other API components

All 3 comments

Marking this as API b/c all PD can do is save a valid JSON - these protocols are specifying the intended behavior eg four_tiprack_test.json pickUpTip commands specify: "pick up tips from column 1-12 in slot 2, then same for slot 3, then slot 10"

This needs to be addressed in the JSON executors or other API components

Unable to reproduce on 3.15.0-alpha.0 using the following protocol. Tentatively, this may be already fixed.

two_tiprack_test.json.zip

  • P300 Multi on right mount
  • 2x 300 碌L tip racks
  • 1x 12 row reservoir
  • 1x 96 well plate

The robot I was testing on had a P300 Multi GEN2 on the right mount. I purposefully calibrated both tip racks 1 row to the right. If #4288 was present on PD protocols, then we'd expect that during the run, those calibrations would sum up and the robot would pick up tips 2 rows over. My observed behavior was that the robot picked up from 1 row over.

I observed a few weird things, though, potentially related to a bad DC or using a GEN2 when the protocol spec'd a GEN1. I will run those to ground and re-test on another robot before marking this issue as fixed

Tested on another robot. Can confirm that this issue is fixed with the upcoming 3.15 release by virtue of the JSON protocol executor switching to the PAPIv2 plumbing

Issues observed in my comment above were definitely caused by bad (or, more specifically, missing) deck calibration data on the robot under test

Was this page helpful?
0 / 5 - 0 ratings