feat(api): implement the liquid transfer function #17179
+414
−134
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
ddcc4
reviewed
Jan 7, 2025
| 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?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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