Skip to content

refactor(api): make estimating liquid height after pipetting account for nozzles/well#18167

Merged
caila-marashaj merged 4 commits intochore_release-8.4.0from
RQA-4129-fix-multi-channel-mrp
Apr 24, 2025
Merged

refactor(api): make estimating liquid height after pipetting account for nozzles/well#18167
caila-marashaj merged 4 commits intochore_release-8.4.0from
RQA-4129-fix-multi-channel-mrp

Conversation

@caila-marashaj
Copy link
Copy Markdown
Contributor

@caila-marashaj caila-marashaj commented Apr 24, 2025

Overview

Well volume tracking in update_types multiplies any volume being handled by the number of nozzles per well. Estimating liquid heights for operations that haven't happened yet, should require a Mount argument, get the nozzle map of the pipette on that mount, and do the same

Changelog

  • make estimate_liquid_height_after_pipetting take in a Mount argument
  • make the predictive geometry functions take in a pipette_id, and only make sure it's there in the logical paths that need it
  • multiply the volume difference when finding a volume offset by nozzles/well

Review Requests

Should I just use MountType? I did Mount because I thought people are more likely to use that in protocols but ¯_(ツ)_/¯

@caila-marashaj caila-marashaj requested review from a team as code owners April 24, 2025 15:15
@caila-marashaj caila-marashaj requested review from shlokamin and removed request for a team April 24, 2025 15:15
@caila-marashaj caila-marashaj changed the base branch from edge to chore_release-8.4.0 April 24, 2025 15:15
@caila-marashaj caila-marashaj force-pushed the RQA-4129-fix-multi-channel-mrp branch from 425417e to 8acdbab Compare April 24, 2025 15:18
Copy link
Copy Markdown
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protocol API functions should take the least complex type possible, in this case the string name of the mount or even possibly the instrument object - we should never require that someone import something in their protocol.

Comment thread api/src/opentrons/protocol_api/labware.py Outdated
Copy link
Copy Markdown
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me once tested on hardware!

@caila-marashaj caila-marashaj merged commit 7465bcf into chore_release-8.4.0 Apr 24, 2025
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants