Skip to content

docs(api): liquid classes in API 2.23#17992

Closed
emilyburghardt wants to merge 8 commits into
chore_release-8.4.0from
docs-liquid-class
Closed

docs(api): liquid classes in API 2.23#17992
emilyburghardt wants to merge 8 commits into
chore_release-8.4.0from
docs-liquid-class

Conversation

@emilyburghardt
Copy link
Copy Markdown
Collaborator

@emilyburghardt emilyburghardt commented Apr 4, 2025

Overview

the beginning of liquid classes in API 2.23! will keep committing on this next week.

Test Plan and Hands on Testing

sandbox: http://sandbox.docs.opentrons.com/docs-liquid-class/v2/

Changelog

  • adding a new liquid classes article (do we like where I put this? I'm not convinced yet)
  • changes throughout complex commands section: defining and separating basic (OG) from liquid class complex commands. not entirely restructuring this section in favor of the liquid class commands yet. As you can see throughout, there are several sections (like Complex Liquid Handling Parameters) where it still makes sense to have transfer() front and center. When we document how users can edit their liquid class in 8.5, it will make more sense to begin centering the new liquid class commands.
  • TODO: update article for new table code, check partial tip section to include decision on well visiting. how is blowout location determined for a liquid class? review my own changes and add questions for engineers.

Review requests

  • this article is not a breezy read currently. it is thick, but more technically accurate than it was in my first draft
  • ISO ideas on the properties list/table, and appendix with liquid class definitions

Risk assessment

low.

Copy link
Copy Markdown
Contributor

@jwwojak jwwojak left a comment

Choose a reason for hiding this comment

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

A few comments for consideration. Wow, this is a big pr.

dest=plate["A2"],
)

This time, including the ``glycerol_50`` liquid class definition optimizes transfer behavior on the Flex for your viscous liquid.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Consider striking "This time." Start with "including."

Suggested change
This time, including the ``glycerol_50`` liquid class definition optimizes transfer behavior on the Flex for your viscous liquid.
Including the ``glycerol_50`` liquid class definition optimizes transfer behavior on the Flex for your viscous liquid.

Liquid Classes
***************

At the core of your protocol are liquid transfers, the liquid handling steps the robot performs to move liquids in labware.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I wonder about improving the intro sentence some. A good opener is always challenging.

Maybe just a good old "This section explains how to use liquid classes in your protocols. Identifying liquids by class can help [optimize, improve, dealer's choice] transfer performance" or some such.


Each Opentrons-verified liquid class is defined by a set of properties:

.. list-table::
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

List tables, yessssss.

* - Blowout
- Larger volume of air the pipette dispenses to ensure all liquid leaves the tip.

A :ref:`liquid class definition <liquid-class-definitions>` specifies values for each property based on the liquid class. When you transfer with a liquid class in your protocol, transfer behavior based on each property is automatically applied. For example, when you use `.InstrumentContext.transfer_with_liquid_class` to transfer a viscous liquid, your Flex pipette automatically submerges more slowly into the liquid to prevent air bubbles from forming.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is a style-only comment. There's something about the "When you transfer ... property is automatically applied" sentence. Passive voice. Something has to do the applying, the class? the protocol?

"When your protocol includes a liquid class, the characteristics of that class control transfer behavior."

Something something.


A :ref:`liquid class definition <liquid-class-definitions>` specifies values for each property based on the liquid class. When you transfer with a liquid class in your protocol, transfer behavior based on each property is automatically applied. For example, when you use `.InstrumentContext.transfer_with_liquid_class` to transfer a viscous liquid, your Flex pipette automatically submerges more slowly into the liquid to prevent air bubbles from forming.

Properties marked with an asterisk, shown above, are determined by your pipette, tip, and volume combinations. For more information, see :ref:`liquid-class-definitions`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Passive voice here, but I don't have a good suggestion. Probably fine to just leave it alone. Into every paragraph, a little PV may fall.

Opentrons-verified Liquid Classes
=================================

Opentrons-verified liquid classes are liquid class definitions based on the properties of a specific liquid:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could we strike "liquid class definitions"?

Suggested change
Opentrons-verified liquid classes are liquid class definitions based on the properties of a specific liquid:
Opentrons-verified liquid classes are based on the properties of a specific liquid:

or maybe, "Opentrons-verified liquid class definitions are based on the properties of a specific liquid."

- Based on 50% glycerol
- ``glycerol_50``

You can define and specify liquid classes in your protocols to automatically apply transfer behavior like flow rate, submerge and retract speeds, and advanced settings optimized for your liquid class.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This sentence is doing a lot of work, too much perhaps. Let's try to break it up and slow things down some.

Suggested change
You can define and specify liquid classes in your protocols to automatically apply transfer behavior like flow rate, submerge and retract speeds, and advanced settings optimized for your liquid class.
You can define and specify liquid classes in your protocols. The class characteristics automatically control transfer behavior. This includes settings like flow rate, submerge and retract speeds, and other advanced parameters specific to that class.

Selecting a Liquid Class
========================

You'll use a :ref:`liquid class definition <liquid-class-definitions>` in your protocol to optimize transfer behavior based not only on liquid properties, but on your chosen Flex pipette and tips. Start by defining the tips, trash, pipette, and labware used in your transfers. Then, use :py:meth:`.ProtocolContext.define_liquid_class` to select a liquid class.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This:

based not only on

stands out a bit.

Consider striking it. Try, "You'll use a :ref: liquid class definition <liquid-class-definitions> in your protocol to optimize transfer behavior based on liquid properties, along with your chosen Flex pipettes and tips."

liquid_3 = protocol_context.define_liquid_class("glycerol_50")


You'll need to add a label to liquid classes in your protocol, like ``liquid_1``. Not only does this help you keep track of multiple liquids of the same class in a protocol, but ``transfer_with_liquid_class()`` requires a label previously defined in your protocol instead of a liquid class load name, like ``glycerol_50``.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Again, watch out for that negation, "Not only". Instead, start that second sentence as "This label helps you track multiple liquids of the same class in a protocol."

And then go on to finish with, "It is also required by transfer_with_liquid_class() instead of a liquid class load name like glycerol_50.

Liquid Class Transfers
======================

Use ``transfer_with_liquid_class`` to transfer an aqueous, volatile, or viscous liquid defined in your protocol. Here, you'll specify your liquid, volume, source, and destination wells, tip handling preferences, and the trash location.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is a method? Maybe should be, "Use the transfer_with_liquid_class() method to...

And then, "This method accepts arguments that let you specify your liquid, volume, source, and destination wells, tip handling preferences, and the trash location.

ecormany added a commit that referenced this pull request Apr 9, 2025
# Overview

Adding methods like `transfer_with_liquid_class()` to the API reference.

Addresses RTC-610.

Any follow-up edits to these docstrings can be handled in #17992.

## Test Plan and Hands on Testing


[Sandbox](http://sandbox.docs.opentrons.com/api-ref-liquid-classes/v2/new_protocol_api.html)

## Changelog

- Param descriptions for the three main liquid class methods.
- Unhide the methods
- Add `LiquidClass` to the ref.
- Nitpicks to allow docs to build.

## Review requests

Are these "good enough"? Want to get these merged to keep other liquid
class docs work moving.

## Risk assessment

low, docs
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 10, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 28.90%. Comparing base (b40363d) to head (a4fa27b).
Report is 1 commits behind head on chore_release-8.4.0.

Additional details and impacted files

Impacted file tree graph

@@                 Coverage Diff                  @@
##           chore_release-8.4.0   #17992   +/-   ##
====================================================
  Coverage                28.90%   28.90%           
====================================================
  Files                     3101     3101           
  Lines                   235493   235493           
  Branches                 19129    19130    +1     
====================================================
  Hits                     68081    68081           
  Misses                  167388   167388           
  Partials                    24       24           
Flag Coverage Δ
protocol-designer 18.80% <ø> (-0.01%) ⬇️
step-generation 4.34% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Comment on lines +40 to +60
1. Pick up tip
2. Submerge into the source to the aspirate position
3. Delay for an amount of time
4. Mix at the aspirate position
5. Pre-wet the attached tip at the aspirate position
6. Aspirate from source
7. Delay for an amount of time
8. Retract from the source to the specified position
9. Touch tip at source
10. Add an air gap
11. Move to and submerge into the destination to the dispense position
12. Delay for an amount of time
13. Dispense into destination
14. Push out into destination
15. Delay for an amount of time
16. Mix at the dispense position
17. Retract from the dispense to the specified position
18. Delay for an amount of time
19. Blow out at the specified location
20. Touch tip at the blow out location
21. Drop tip
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This asks a reader to look at a 21-step list. Is this really necessary? Instead, I'd suggest breaking this up into related, but sequential groups, and then summarized in sentences (maybe with a few bullets or list items). Even if you have to make up artificial categories to do this, it might be worth it. Example:

Initial process
Summarize 1–8: Pick up tip, get some liquid, retract to do the next thing.

Air gap process
Summarize 9–10: air gap and move to destination

Dispense process
Summarize 11–14: dispensing into a destination

Dispense process II
Summarize 15–18: Delay, mix, retract, delay

Final process
Summarize 19–21: Everything else that finishes up.

These are all arbitrary so use your best judgement, but the point is, the list could be summed up in a few readable sentences. You'd also have room to add some description/explanation if needed.

Could even try a table:

Process category Description
Initial aspiration Some explanation here
Another process category Some explanation here
Another process category Even more explanation


The eight pipette channels will only dispense into every other well in the column: B1, D1, F1, H1, J1, L1, N1, and P1.

Complex Commands
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Tiiiiny start of a section I made to begin on the differences in multi-channel movement between the building block command examples we use and updated liquid class commands.

I understand this the least- might need some engineer time next week.

@ecormany
Copy link
Copy Markdown
Contributor

Closing in favor of #18619.

@ecormany ecormany closed this Jun 16, 2025
emilyburghardt added a commit that referenced this pull request Jul 3, 2025
<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

Liquid classes in API 2.24. Includes new articles covering liquid
classes and liquid class definitions, plus changes throughout our
Complex Commands section.


<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->

## Changelog
-brought over liquid classes text from [PR
#17992](https://github.com/Opentrons/opentrons/pull/17992/files#diff-0f90fc8fd15163b9fb8b128ac3c358036fbb7bef07c549fbdbec8b45cb26af51)
- reorganized the liquid classes article to ease into property
descriptions
- build issues with images in the properties table; currently in the
docs as a list to avoid this.
- adding custom liquid class creator section (and differentiate between
customizing and *creating* from scratch)
- built out liquid class definition tables section 
- updated API reference for tip handling options, `get_liquid_class` and
`define_liquid_class` entries
- linked users to github schema for creating their own liquid class 

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

---------

Co-authored-by: Edward Cormany <edward.cormany@opentrons.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs papi-v2 Python API V2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants