-
Notifications
You must be signed in to change notification settings - Fork 178
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.
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
Pipette model offsets #838
Conversation
…del-offset or mount
… calibration data
Codecov Report
@@ Coverage Diff @@
## edge #838 +/- ##
==========================================
+ Coverage 69.26% 69.42% +0.15%
==========================================
Files 233 233
Lines 7181 7221 +40
Branches 312 312
==========================================
+ Hits 4974 5013 +39
- Misses 2118 2119 +1
Partials 89 89
Continue to review full report at Codecov.
|
5535264
to
31418c9
Compare
31418c9
to
48d8c6e
Compare
520d8f5
to
9ee9d82
Compare
13df478
to
1bef385
Compare
1958f72
to
dfeec9b
Compare
dfeec9b
to
0a1dcb9
Compare
api/opentrons/instruments/pipette.py
Outdated
@@ -181,6 +186,11 @@ def __init__( | |||
self.set_flow_rate( | |||
aspirate=aspirate_flow_rate, dispense=dispense_flow_rate) | |||
|
|||
# TODO (andy): remove from pipette, move to tip-rack | |||
self.robot.config.tip_length[self.name] = \ | |||
self.robot.config.tip_length.get(self.name, tip_length) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the initialization parameter as the fallback here makes it such that if the tip length has previously been set in the config, whatever is specified in initialization would not be honored. I think the logic here should be reversed: if not tip_length, check config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overwriting the length specified in initialization is intentional here. Pipettes are initialized before every protocol run, each with a default tip-length depending on the model. If the tip has already been probed, then we do not want to use that default length. Solving this confusion should probably be done in another PR by saving all tip-length measurements to the associated tip-rack labware
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the purpose of this parameter to serve as a fallback length perhaps renaming the parameter to fallback_tip_length
or something similar would lessen the confusion until we are able to move tip length to labware definitions.
This strikes me as related to the problems we had when there was no split between a labware definition and labware calibration
api/opentrons/instruments/pipette.py
Outdated
# TODO (andy): remove from pipette, move to tip-rack | ||
self.robot.config.tip_length[self.name] = \ | ||
self.robot.config.tip_length.get(self.name, tip_length) | ||
robot_configs.save(self.robot.config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should save here. In general, I'm not actually super confident in the logic of save, and I think using it more often adds risk around bad override values being stored
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes for the datetime thing because lack of consistency in this area has caused problems before
api/opentrons/robot/robot_configs.py
Outdated
|
||
if version in migration_functions: | ||
# backup the loaded configuration json file | ||
tag = datetime.now().isoformat().split('.')[0].replace(':', '-') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure how this logic is used, or if it's even part of this PR vs a copy-paste thing, but any datetimes should be formatted in ms since epoch (see #365 for context and discussion). Additionally, datetime.now().isoformat()
is in local timezone, not UTC (not a problem with ms since epoch)
api/opentrons/robot/robot_configs.py
Outdated
if version in migration_functions: | ||
# backup the loaded configuration json file | ||
tag = datetime.now().isoformat().split('.')[0].replace(':', '-') | ||
tag += '-v{}'.format(version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I'm already commenting on this stuff: this tag construction may be easier to understand as a single format call:
tag = '{}-v{}`.format(
int(time.time() * 1000),
version)
api/opentrons/robot/robot_configs.py
Outdated
migrate_func = migration_functions[version] | ||
config_json = migrate_func(config_json) | ||
# recursively update the config | ||
# until there are no more migration methods for it's version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's
vs its
typo 😛
api/opentrons/instruments/pipette.py
Outdated
@@ -181,6 +186,11 @@ def __init__( | |||
self.set_flow_rate( | |||
aspirate=aspirate_flow_rate, dispense=dispense_flow_rate) | |||
|
|||
# TODO (andy): remove from pipette, move to tip-rack | |||
self.robot.config.tip_length[self.name] = \ | |||
self.robot.config.tip_length.get(self.name, tip_length) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the purpose of this parameter to serve as a fallback length perhaps renaming the parameter to fallback_tip_length
or something similar would lessen the confusion until we are able to move tip length to labware definitions.
This strikes me as related to the problems we had when there was no split between a labware definition and labware calibration
…del-offset or mount
… calibration data
3c9dab6
to
b3e5022
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works with the following protocol:
from opentrons import containers, instruments, robot
rack1 = containers.load('tiprack-200ul', '3')
rack3 = containers.load('tiprack-200ul', '6')
plate = containers.load('96-flat', '1')
p300_single = instruments.P300_Single(
mount='right',
tip_racks=[rack1]
)
p300_single_2 = instruments.P300_Single(
mount='left',
tip_racks=[rack1]
)
p300_single.pick_up_tip()
p300_single.aspirate(30, plate.wells('A1'))
p300_single.dispense(30, plate.wells('B1'))
p300_single.move_to(plate.wells('B5'))
p300_single.drop_tip()
p300_single_2.pick_up_tip(rack1.wells('B1'))
p300_single_2.aspirate(5, plate.wells('A1'))
p300_single_2.dispense(5, plate.wells('A2'))
p300_single_2.move_to(plate.wells('A6'))
p300_single_2.drop_tip()
Without calibrating the second model to the labware.
c2d0220
to
ae113f1
Compare
ae113f1
to
8a22960
Compare
overview
Fixes #817
This PR adds the property
model_offset
to pipette config, which is used to describe the dimensional differences between pipette. For example, a dimensional difference is that theP10_Single
pipette is longer than theP300_Single
changelog
This PR refactors
config.instrument_offset
to store just the delta between what was expected vs what was found from tip-probe. Previously,config.instrument_offset
described the entire offset of that instrument, including any offset from the pipette model's dimensions, so it could not be re-used between different models.This PR also adds a
version
property torobot_config
, to allow migrating from old configurations version to new ones.Lastly, something that should be changed later on, is that the tip-length per pipette is saved in the robot config file. For example, if was using a
P10_Single
pipette, the generated config file would contain atip_length
key that looks like:Later on, this
tip_length
should be a property of a tip-rack, not the pipette. This way, multiple pipettes can share the same tips without requiring a new tip-probe. Also, this way a single pipette can use multiple tips during a protocol run.