Skip to content
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

feat(api): add liquid state property #15553

Closed
wants to merge 2 commits into from

Conversation

caila-marashaj
Copy link
Contributor

@caila-marashaj caila-marashaj commented Jul 1, 2024

Overview

This adds a liquid_presence_state property to the protocol api's instrument context, along with an enum for the possible states.

The value here is Optional and defaulted to None, which I think makes sense for the ot2 case.

Changelog

  • add getter and setter for liquid_presence_state
  • add LiquidPresenceState enum in opentrons.types

Review Requests

Is there any further error handling/prevention I should do for ot2 instruments?

@caila-marashaj caila-marashaj requested a review from a team as a code owner July 1, 2024 14:02
Copy link
Contributor

github-actions bot commented Jul 1, 2024

A PR has been opened to address analyses snapshot changes. Please review the changes here: https://github.com/Opentrons/opentrons/pull/

@caila-marashaj caila-marashaj force-pushed the EXEC-543-liquid-state-property branch from ee5df52 to 2adb717 Compare July 1, 2024 14:03
Copy link
Contributor

github-actions bot commented Jul 1, 2024

A PR has been opened to address analyses snapshot changes. Please review the changes here: #15554

Copy link
Contributor

@ecormany ecormany left a comment

Choose a reason for hiding this comment

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

Couple comments. I may be confused as to what distinguishes this from InstrumentContext.liquid_detection, so ignore me if I'm off base.

@@ -1642,6 +1643,16 @@ def flow_rate(self) -> "FlowRates":
"""
return self._core.get_flow_rate()

@property
@requires_version(2, 0)
Copy link
Contributor

Choose a reason for hiding this comment

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

2.20, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep ty

def liquid_presence_state(self) -> Optional[types.LiquidPresenceState]:
return self._liquid_presence_state

@liquid_presence_state.setter
Copy link
Contributor

Choose a reason for hiding this comment

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

Would we want a public setter, or should this always be driven by sensor measurements?

@caila-marashaj
Copy link
Contributor Author

Couple comments. I may be confused as to what distinguishes this from InstrumentContext.liquid_detection, so ignore me if I'm off base.

InstrumentContext.liquid_detection is a bool that would enable liquid probing before an aspirate, and this new property will hold the current state of liquid presence in a well. So after a liquid probe, we would update this new state to be PRESENT, ABSENT, or UNKNOWN.

But you raise a good point in that now that we're adding to this it would be good to update that name to enable_liquid_detection or something.

Copy link
Contributor

github-actions bot commented Jul 1, 2024

A PR has been opened to address analyses snapshot changes. Please review the changes here: #15554

@caila-marashaj
Copy link
Contributor Author

whoopsie duplicate ticket

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