feat(api): implement the liquid transfer function #17179
Conversation
sanni-t
changed the base branch from
edge
to
AUTH-866-add-transfer-flow-builder-2
sanni-t
requested review from
jbleon95 and
ddcc4
and removed request for
a team
| pip_api_name | ||
| for pip_api_name, pip_name in PIPETTE_API_NAMES_MAP.items() | ||
| if pip_name == pipette.pipetteName | ||
| ][0] |
There was a problem hiding this comment.
Small nitpick: This can be more efficiently implemented as:
load_name = next(
(pip_api_name
for pip_api_name, pip_name in PIPETTE_API_NAMES_MAP.items()
if pip_name == pipette.pipetteName),
None
)
assert load_name
return load_name
| @@ -883,7 +904,7 @@ def load_liquid_class( | |||
|
|
|||
| liquid_class_record = LiquidClassRecord( | |||
| liquidClassName=liquid_class.name, | |||
| pipetteModel=self.get_model(), # TODO: verify this is the correct 'model' to use | |||
| pipetteModel=pipette_load_name, # TODO: verify this is the correct 'model' to use | |||
| pipette_load_name=self.get_pipette_name(), # TODO: update this to use load name instead | ||
| tiprack_uri=tiprack_uri, | ||
| pipette_load_name=self.get_pipette_load_name(), | ||
| tiprack_uri=tiprack_uri_for_transfer_props, | ||
| ) | ||
| transfer_props = liquid_class.get_for( |
There was a problem hiding this comment.
self.load_liquid_class() above also calls liquid_class.get_for(), right?
Can you refactor self.load_liquid_class() to just take in the transfer_props directly as an argument?
| @@ -1034,7 +1153,9 @@ def aspirate_liquid_class( | |||
| ) | |||
| components_executor.aspirate_and_wait(volume=volume) | |||
| components_executor.retract_after_aspiration(volume=volume) | |||
| return components_executor.tip_state.last_liquid_and_air_gap_in_tip | |||
| last_contents = components_executor.tip_state.last_liquid_and_air_gap_in_tip | |||
| tip_contents[-1] = last_contents | |||
There was a problem hiding this comment.
Hm, I'm a little confused what this is trying to do: it sometimes modifies the list that's passed in, and it sometimes modifies a list that was created local to this function?
There was a problem hiding this comment.
Talked about it in person. The list that's passed in is not re-used by the caller function so it doesn't matter if the list gets modified here or not, since the list in the caller function gets replaced by ones returned by the aspirate_liquid_class and dispense_liquid_class. But I can see how it can cause confusion so I'll update this to use a copy of the list for any modifications.
Closes AUTH-866
Overview
Final PR of the 3-PR series.
Implements
InstrumentCore.transfer_liquid().The
transfer_liquid()method does the following:aspirate_liquid_class()anddispense_liquid_class()for every source-> destination transfer.This PR also updates the tiprack 'names' to URIs in the liquid class definition in shared data for 'water' only. We will have a separate PR for updating rest of the definitions.
Test Plan and Hands on Testing
transfer_liquid()execution succeeds for various supported configurationsAdditionally, we will be adding analysis snapshot tests with protocols that use various configurations for transferring with liquid classes.
Review requests
transfer_liquid()turned out to be not easily unit-testable, mainly owing to the location of implementation (insideInstrumentCore). I plan on moving this function out of the InstrumentCore so that it can be unit-tested without the constraints of rest of the Instrument core. But this still serves as a robust implementation for doing end-to-end, integration testing so that's what I am focusing on in this PR.Risk assessment
Low. Doesn't change existing API