Requested upgrades to InstrumentContext - dispense and move_plunger

[jweinacht]

This is a follow-up to a recent inquiry where I was asking about the move_to command as I was using hw_manager move_to, which works, but the warning comes up that the function will be deprecated. So the feedback I received was to use the InstrumentContext.move_to. It indeed works, and I am able to move the robot to different areas on the deck!, so thanks for that.

But I realized that there are two other commands I use - dispense and move_plunger that are causing me problems now that I have switched to that. For move_plunger, I have not found an equivalent way to do this move (protocol._hw_manager.hardware._move_plunger(types.Mount.LEFT, droptip, speed=speed*4) - which works, but gives the deprecated warning. Something like drop_tip() requires there to be a tip (and in my application, there is a situation where I need to do this move without a tip), and if I use the home plunger, it does added homing motions, which this command does not do (protocol._hw_manager.hardware._move_plunger(types.Mount.LEFT, bottom, speed=speed/1.2) . So is there a analogous move_plunger, that is not planned to be depreciated that I can use - I could not find one in the documentation?

For the dispense, I now find if I use the InstrumentContext move_to's and then do a dispense call, it will not let me dispense when I move the pipettor to another location on the deck, like I can with the protocol._hw_manager.hardware.move_to. I see there is a validate_can_dispense call that is not liking this and I get "'NoneType' object has no attribute 'parent'. Is there a way to bypass this check - fully understanding - programmer (me)needs to beware of bad consequences.

System working great with what I have set up - only concern is that I am using approaches that are targeted to be deprecated. I contacted Tech Support and they told me to rewrite my protocol to not use the hardware manager(would love to , but have not found one yet for these two moves) or to put in a request - hence this request...

[mcous]

Something like drop_tip() requires there to be a tip (and in my application, there is a situation where I need to do this move without a tip)

This has been on our radar, and you can keep an eye on for our progress here #6243

I see there is a validate_can_dispense call that is not liking this and I get "'NoneType' object has no attribute 'parent'.

This sounds like an unambiguous bug in our code. Can you drop a code snippet in this thread that reproduces this error?

only concern is that I am using approaches that are targeted to be deprecated

• Removal of things marked "deprecated" will not happen without a bump of the Python Protocol API Version
• Even if something it removed in a later version, as long as you keep the same apiLevel in your protocol file itself, everything should keep chugging along just fine as long as your OT-2 supports that API level
• We have no concrete plans to change our API version support on the OT-2 at this time
  • Our minimum supported version at the time of writing is 2.0
  • I would expect both the issues above to be resolved before we felt comfortable changing the minimum supported version
  • This change would come along with other major version number bumps and be heavily communicated
  • Our policy in the past has been to give at least 6 months (or maybe 1 year, my memory is a little fuzzy) notice before any breaking changes to our minimum Python protocol API version

[jweinacht]

Thanks for he response! Feel better that my approach will not be wasted. Will share what I am doing in the near future. Here is an example code snippet:

import opentrons.execute
import json
import time
from opentrons import types
from opentrons.types import Location, Point
protocol = opentrons.execute.get_protocol_api('2.12')
protocol.home()
tiprack = protocol.load_labware('opentrons_96_tiprack_300ul', '6')
pipette_300 = protocol.load_instrument('p300_single_gen2', mount='left', tip_racks=[tiprack])
water_container = protocol.load_labware('opentrons_15_tuberack_falcon_15ml_conical','3')
#instruments = protocol._hw_manager.hardware._instruments_for(types.Mount.LEFT)

tube_loc = 'A1'
x_loc = 104
y_loc = 201
z_loc = 124

pipette_300.pick_up_tip()
pipette_300.aspirate(175, water_container[tube_loc])
pipette_300.move_to(water_container[tube_loc].top(10),"direct")

pipette_300.move_to(Location(Point(x_loc,y_loc,z_loc),None),"direct")
pipette_300.dispense(25)

pipette_300.drop_tip()

I get this(it moves to the location but then generates this error)

AttributeError                            Traceback (most recent call last)
<ipython-input-14-9815fddb0539> in <module>()
     26 # go to location
     27 pipette_300.move_to(Location(Point(x_loc,y_loc,z_loc),None),"direct")
---> 28 pipette_300.dispense(25)
     29 
     30 pipette_300.drop_tip()

/usr/lib/python3.7/site-packages/opentrons/protocols/api_support/util.pyc in _check_version_wrapper(*args, **kwargs)

/usr/lib/python3.7/site-packages/opentrons/protocol_api/instrument_context.pyc in dispense(self, volume, location, rate)

/usr/lib/python3.7/site-packages/opentrons/protocols/api_support/instrument.pyc in validate_can_dispense(location)

/usr/lib/python3.7/site-packages/opentrons/protocols/api_support/instrument.pyc in _is_tiprack(location)

AttributeError: 'NoneType' object has no attribute 'parent'

[mcous]

Yup, this is a bug in our software. I'm going to file a fix and try to get it into our next release (6.1.0).

In the mean time, what does the location (104, 201, 124) represent? The Location class takes two parameters:

1. The deck coordinates
2. The symbolic location (well or labware) that these deck coordinates represent

For argument (2), you've passed in None, which is valid but is also triggering this bug by the time the dispense is happening (because it attempts to re-use the last Location)

pipette_300.move_to(Location(Point(x_loc,y_loc,z_loc),None),"direct")
#                                                     ^^^^

If there's a well that makes sense to associate to these deck coordinates (e.g. water_container[tube_loc]), you may be able to work around the bug without changing the movement behavior of your protocol by passing that well in as the second Location argument rather than None

[jweinacht]

Thanks Mike, It does look like that will work!

[mcous]

The issue with AttributeError: 'NoneType' object has no attribute 'parent' has been resolved and will be in the upcoming 6.1.0 release. Thanks for your report!

I believe the other issue you mentioned - perform drop tip procedure without tip attached - is already tracked in #6243. I'm going to close this issue since I think those are all the items you brought up, but feel free to keep asking questions (or point out anything I missed!)