Chore Release 8.5.0 #18470
Merged
Chore Release 8.5.0 #18470
Conversation
This file contains hidden or 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
Since we have isolated Robot Stack release 8.4 into `chore_release-8.4.0` we must lock down command schema 12 for that Robot Stack Release. If changes are needed to command schema 12 they must first be done in `chore_release-8.4.0` then incorporated in `edge` via a merge back. (cherry picked from commit 1e70394)
(cherry picked from commit 55b6310)
Merge chore_release-8.4.0 mergeback branch into edge Co-authored-by: Josh McVey <josh.mcvey@opentrons.com> Co-authored-by: Jamey Huffnagle <jamey.huffnagle@opentrons.com> Co-authored-by: Ryan Howard <ryan.howard@opentrons.com> Co-authored-by: Sanniti Pimpley <sanni-t@users.noreply.github.com> Co-authored-by: Andy Sigler <andrewsigler1@gmail.com> Co-authored-by: Seth Foster <seth@opentrons.com> Co-authored-by: emilyburghardt <emily.burghardt@opentrons.com> Co-authored-by: Max Marrone <max@opentrons.com> Co-authored-by: Jeremy Leon <jeremy.leon@opentrons.com> (cherry picked from commit 26345e1)
…cter (#17937) This fixes a small problem I noticed with the `/clientData` endpoints. These endpoints have a path parameter that's an arbitrary client-defined ID, like `PUT /clientData/<id>`, `GET /clientData/<id>`. The string ought to be at least one character long, otherwise there's no way to distinguish `DELETE /clientData/<id>`, which deletes the specific entry represented by `<id>`, from `DELETE /clientData/`, which deletes all entries. This PR adds validation for that. (cherry picked from commit 1cddbbd)
…cstring (#17980) # Overview @ddcc4 spotted a typo in the code sample in this docstring. We accidentally used the deprecated pipette delay method, instead of the proper protocol delay method. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/fix-delay-in-prepare_to_aspirate-docstring/v2/new_protocol_api.html#opentrons.protocol_api.InstrumentContext.prepare_to_aspirate) ## Changelog - Use the right method - Parentheses on method name 🧐 ## Review requests best to put this in `edge`, no? ## Risk assessment nil (cherry picked from commit 2dabd34)
…t_context.py (#17994) # Overview For some reason, we were mocking out the entire `protocol_api/validation.py` module in `test_instrument_context.py`. There is no reason to do that, since the validation functions are pure functions that don't rely on external objects, and we really ought to test the validation functions in our tests. Furthermore, we were abusing the mocks to make the validation functions do wild things: like mistranslating `Location`s into `WellTarget`s, or turning the `"never"` tip-replacement policy into `TransferTipPolicyV2.ONCE`. There is no good reason to do that, and it just makes the test logic ridiculously hard to follow. I need to fix this because I want to write a test for my change to the `mix()` function, but it was very hard to do so given how we were using `mock_validation`. ## Test Plan and Hands on Testing I examined all the usages of `mock_validation` by hand. It was very painful. ## Risk assessment Low. This is a test-only change. (cherry picked from commit 2fece0c)
# Overview This adds the new argument `mm_from_edge` to the `touch_tip()` public API function. The option is needed for PD protocols. And we generally think that it makes more sense for users to specify `mm_from_edge` instead of `radius`. Support for `mm_from_edge` already exists in the Protocol Core and Engine (PR #17107), so all we need to do is to pass the new argument along to the Core. We follow the same convention that we adopted in the Protocol Engine, that `radius` and `mm_from_edge` are mutually exclusive, so if the user specifies `mm_from_edge`, they must leave `radius` to its default value of 1.0 ## Test Plan and Hands on Testing I added unit tests to check for all combinations of `mm_from_edge` and `radius`. ## Review requests Do I need to do anything else for API versioning? What API version would this go into? ## Risk assessment Medium. We're adding a new API option, and we have to support API changes forever once released. (cherry picked from commit 63f1512)
Merging the latest chore_release-8.4.0 back to edge. Plus adding a fix for command schema 13 that was not available for release branch. --------- Co-authored-by: Josh McVey <josh.mcvey@opentrons.com> Co-authored-by: Jamey Huffnagle <jamey.huffnagle@opentrons.com> Co-authored-by: Ryan Howard <ryan.howard@opentrons.com> Co-authored-by: Sanniti Pimpley <sanni-t@users.noreply.github.com> Co-authored-by: Andy Sigler <andrewsigler1@gmail.com> Co-authored-by: Seth Foster <seth@opentrons.com> Co-authored-by: emilyburghardt <emily.burghardt@opentrons.com> Co-authored-by: Max Marrone <max@opentrons.com> Co-authored-by: Sarah Breen <sarah.breen@opentrons.com> Co-authored-by: Jeremy Leon <jeremy.leon@opentrons.com> Co-authored-by: Jethary Alcid <66035149+jerader@users.noreply.github.com> Co-authored-by: TamarZanzouri <zanzouritamar@gmail.com> Co-authored-by: Ed Cormany <edward.cormany@opentrons.com> Co-authored-by: Caila Marashaj <98041399+caila-marashaj@users.noreply.github.com> (cherry picked from commit 3692478)
# Overview Change build process so only the PAPI v2 docs get built on every push. [Update: also keeping hardware docs dynamic.] Addresses RTC-711, although followup work may need to be done on AWS directly to add some robots.txt rules. ## Test Plan and Hands on Testing Spot check sandbox sites against current prod: - http://sandbox.docs.opentrons.com/infra-stop-building-old-docs/ot1/index.html - http://sandbox.docs.opentrons.com/infra-stop-building-old-docs/v1/index.html Everything should look the same. Not perfect, there is some formatting jankiness that I'm not attempting to fix. ## Changelog - new git ignore rules to track built copies of the archived docs sites - commit a copy of both sites - change `make -C api docs` to only build v2 and hardware docs. other sites can still be built, if needed, with other `make` commands. ## Review requests - **Is this the right way to go about this?** It works, but does it work how we want? - Is there anything in the Sphinx output that should still be ignored? I think not, but I'm not 100% - Double check built sites. - Also now is the time to speak up if you think any of these sites should go away forever 🚮 ## Risk assessment low-ish. you should basically never notice. (cherry picked from commit eb3aeb7)
…cent factory trip (#18021) <!-- 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 Everything is working smoothly on mp.96ch.200 branch, this is that branch, rebased onto edge and smoothed over so it can be merged into edge. <!-- 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 <!-- 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: Mehdi Zaidi <55298601+meh-di@users.noreply.github.com> Co-authored-by: Carlos <fernandez.carlos40@gmail.com> Co-authored-by: caila-marashaj <caila.marashaj@opentrons.com> Co-authored-by: Andiiiiiiyy <andy.hu@opentrons.com> Co-authored-by: wweiye <275241708@qq.com> Co-authored-by: Jerome <1458798121@qq.com> (cherry picked from commit ff9e95b)
* refactor(shared-data): change liquid classes order (cherry picked from commit 0de3e83)
(cherry picked from commit 5b94322)
(cherry picked from commit bf13009)
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
# Overview Lint the Python protocol files distributed as part of the v2 API docs. Addresses RTC-137. ## Test Plan and Hands on Testing 1. Add `docs/v2/example_protocols` to the `black` command `make -C api lint` and `make -C api format`. Was going to add it to `flake` as well, but these files deliberately violate some `flake` rules, like never explicitly referring back to the trash bin but definitely requiring one to pass analysis. 2. Everything should fail because I formatted these files with tabs like a heathen. 3. Run `format` and hopefully everything works. ## Changelog - [x] Update Makefile - [x] Update Python protocols to pass new lint ## Review requests Cool cool? ## Risk assessment v low, shouldn't introduce any CI failures unless the example protocols are modified (cherry picked from commit 8e72a89)
# Overview Flow rates are, in fact, rates measured in **µL/s**. ## Test Plan and Hands on Testing sandbox ## Changelog Fix the unit and true up the table cells. ## Review requests squirrel? ## Risk assessment none (cherry picked from commit 67cffae)
The Makefile targets `test-py` and `circular-dependencies-js` were running a bunch of subcommands serially even though those subcommands were logically independent. This splits them up into recipes that can be run in parallel with `make -j`, following the existing pattern based on `%` wildcards. (cherry picked from commit bc8fcd6)
# Overview Python API docs PR corresponding to changes in #18180. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/docs-combo-adapters-retired/v2/new_labware.html#loading-together) ## Changelog - Moves all mention of combination adapters into a note. - Indicates that they are deprecated as of API version 2.15 (which they effectively have been, even if we didn't strongly discourage their use). - List a couple features that will not work with them and say that future features are also not guaranteed. ## Review requests just accuracy ## Risk assessment nil (cherry picked from commit ec1ec02)
This fixes what I suspect are mistakes in our GitHub Actions workflows, which, in edge cases, could cause problems like workflows not triggering when they should. For instance: `*` looks like it's meant to match everything, but for that, we really want `**`, otherwise we fail to match things that contain slashes. `dir1/**/*.py` looks like it's meant to match any `.py` file under `dir1/`, but I think it will only match things like `dir1/dir2/file.py` and `dir1/dir2/dir3/file.py`, and fail to match things like `dir1/file.py` (cherry picked from commit 3c8b7fa)
# Overview Any movement related commands in the robot context should have run logs associated with them. ## Test Plan and Hands on Testing 1. Check that run logs get generated for robot commands. ## Changelog - Add run logs to robot context commands ## Review requests Check that the run log messages make sense. ## Risk assessment Low. Adding run logs to un-used API. --------- Co-authored-by: Seth Foster <seth@opentrons.com> (cherry picked from commit 3782455)
This deletes the `opentrons.protocol_engine.state.update_types.SIMULATED` sentinel object, which was not used for anything. (cherry picked from commit d0499e1)
Closes AUTH-1653 # Overview Meniscus relative positions for aspirate & dispense will now be relative to the position of meniscus of the liquid *after* the aspirate or dispense action. Updated the `absolute_point_from_position_reference_and_offset()` function to use `well.estimate_liquid_height_after_pipetting()` instead of `well.meniscus()` ## Risk assessment Low. Only affects meniscus-relative pipetting locations (cherry picked from commit 7429fae)
Closes EXEC-1466 Currently, when requesting a command slice or a command error slice via the HTTP API, the exact behavior varies depending on the run status, the “current” status of the run, and which parameters are (or are not) supplied. The behavior varies in the following way: * When invoking get_slice with identical cursor and pageLength parameters, there is inconsistency in the number of returned commands when the run is in a recovery state. * When a run is historical, an unsupplied cursor but a supplied pageLength returns the most recent pageLength commands, however, when a run is current, only the most recently running/executed command is returned. * The above always applies to run command errors. This commit fixes those issues by standardizing behavior in a manner that is most useful given typical client access patterns: if a cursor is not supplied but a pageLength is supplied, we return the pageLength most recent commands and command errors (so all behavior reflects the current behavior if the command slice is derived from a historical run). After doing a complete client-side audit, the client actually seemingly expects the API to behave this way, and has fortunately worked by chance. (cherry picked from commit 2c374ff)
(cherry picked from commit 5af0934)
…turn_tip (#18715) Fixes bugs related to tracking picked up or returned tips between liquid class transfers
) Closes RQA-4304 # Overview The check that verifies that a submerge start location or retract end location is not inside the liquid in well relies on knowing the height of the liquid- either by calculating it based on liquid volume and well inner geometry or by probing into the well. We already skip the check if we don't know the liquid volume or haven't probed the well yet, opting to simply log the decision instead. We should also skip the check if a well's innergeometry isn't present either otherwise the check will raise errors for any labware that doesn't have inner geometry defined, like the `smc_384_read_plate`, or if it's a custom labware. So this PR makes it so that the check excepts on `IncompleteLabwareDefinitionError` as well. ## Risk assessment Low. Only skips a check that would have errored without being useful.
…ass displayNames (#18738) # Overview This fixes a broken test after PR #18711, which changed the names of our liquid classes (AUTH-2003). Specifically, we renamed `Volatile` to `Volatile (80% ethanol)`. ## Test Plan and Hands on Testing Ran test locally. Will also see if CI tests pass. ## Risk assessment Low, test only.
… apart (#18745) # Overview Some time ago, we added `with-ot-hardware: ['true', 'false']` to the test matrix for the `opentrons package tests`, but we didn't update the test name with the new variable. This makes it look like the same test is running twice in CI, which is confusing. This change just adds the `with-ot-hardware` to the test name. ## Test Plan and Hands on Testing Run the CI tests and see. ## Risk assessment Low, cosmetic change for Github display.
…s after retesting (#18675)
Closes AUTH-2018 # Overview Removes auto-probing during LC-based transfer, consolidate & distribute to avoid having this non-tested and not-fully-defined feature in the release. ## Risk assessment None. Removes a pretty isolated feature.
…ce commands (#18759) Closes RABR-791
…id class transfers (#18757) Updates error messages to make them more clear when using group_wells=True with liquid class transfer functions
…t. (#18742) <!-- 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 Tuck in the last few hardware-testing changes into the 8.5 release. <!-- 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 Does not touch public code so no testing required. <!-- 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 <!-- 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. -->
(cherry picked from commit 03b3054)
# Overview In PR #18711 (AUTH-2003), we changed the liquid class display names to: `Aqueous (Deionized water)` / `Volatile (80% ethanol)` / `Viscous (50% glycerol)`. But we've decided we want to change the display names back. So: - displayName: `Aqueous`, description `Deionized water`, loadname: `water` - displayName: `Volatile`, description `80% ethanol`, loadname: `ethanol_80` - displayName: `Viscous`, description `50% glycerol`, loadname: `glycerol_50` https://opentrons.slack.com/archives/C07JJA1AJFQ/p1751036532344239?thread_ts=1750692306.637929&cid=C07JJA1AJFQ This PR reverts #18711 and #18738, and was generated by `git revert` with no manual changes: ``` git revert ec54caf 968ddc8 ``` ## Test Plan and Hands on Testing Running CI tests. ## Review requests This is what we want now, right? ## Risk assessment Low, but we're cutting it close.
Don't crash the entire app when this happens. Closes RQA-4308
<!-- 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 Updates to the Liquid Control page for PD interop + new params added. <!-- 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. --> sandbox: http://sandbox.docs.opentrons.com/docs-pd-interop-8.5/v2/ ## Changelog -added description for ``flow_rate`` param in aspirate/dispense commands (and contrast with ``rate``). checked the API reference entries. - added description for air gap ``in_place`` and ``flow_rate`` parameters (and contrast with ``rate``) - added description for ``mm_from_edge`` behavior and warning. <!-- 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. --> Need to confirm the warning for ``mm_from_edge`` in touch tip. ## 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. --> low.
This reverts #18450 and #18479 to revert to digicert signing for our windows builds. The digicert certificate has the Common Name "Opentrons Labworks Inc." and the ATS cert has the common name "OPENTRONS LABWORKS INC.". These were both determined automatically by the CA from our identity submissions, as is apparently required in the code signing cert baseline requirements. Why are they different? A mystery for the ages. In either case, electron-updater requires that _if_ you specify a `publisherName` in your `app-update.yml` (which we do specifically on windows, since it is generated from our electron-builder config and on windows we set it because nsis packager wants it for doing signing in the first place) _then_ the autoupdate package that will be installed must have a CSC CN exactly matching an entry in `publisherName` or the update will fail. Therefore updates in between <=8.4.1 and >=8.5.0 would fail if we switched to ATS. Instead, we'll switch back to digicert for now; we'll build the new CN into our publisher names; and then whenever we're confident enough people are on >=8.5.0 and therefore have the new publisher names, we'll switch over again (we can't switch immediately because we don't do incremental updates, just full overwrites, so the intermediate update state would go away). This is upsetting. ## Testing - [x] the signing has to work again, which is never guaranteed given the shonky state of dco integration - [x] we should make sure we can update from 8.4.1 to this by making sure the CN of the digital signature on the build from this pr is exactly `Opentrons Labworks Inc.` (and updating to it in the resulting alpha) - [x] we should make sure we can update from this to something signed with the new cert (by mucking around with the latest-alpha or something? or just checking that the app-update.yml in the app's install directory has both names) Supercedes #18785 for build branch name reasons.
…#18802) # Overview In `distribute_with_liquid_class()`, we were dispensing into the same destination well twice when the distribute consists of multiple tip-fills. The bug was caused by the reuse of the variable `next_dest` in `distribute_with_liquid_class()`. `next_dest` in the outer loop is supposed to contain the next well that we have not dispensed to yet. However, we accidently overwrote the variable because we also use it as a loop variable for an unrelated inner loop: ``` for next_vol, next_dest in vol_dest_combo: ``` ## Test Plan and Hands on Testing Using `analyze`, I confirmed that the double-dispense happened with Andy's example before this change, and that it was fixed after this change. I also updated `test_order_of_water_distribution_steps_using_multi_dispense()` to perform a distribute that requires multiple tip-fills, and changed the test to check that we're dispensing into specific wells instead of `dest=mock.ANY`. I confirmed that the bug happened before this change, and it was fixed after this change. ## Risk assessment Medium: this is change deep inside our implementation. But it's necessary to fix the bug.
# Overview Addresses #18803 > The documentation found [here](https://docs.opentrons.com/v2/parameters/defining.html?#the-add-parameters-function), i.e. the "The add_parameters() Function" section of the page on "Defining Parameters", has the wrong type annotation. It is documented as Parameters when it should be ParameterContext. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/docs-fix-rtp-annotation/v2/parameters/defining.html#the-add-parameters-function) ## Changelog 1-liner ## Review requests nothing special. ## Risk assessment nil
…sfers (#18818) Calculate correction by volume by keying on the volume after aspiration and dispense, not the aspirate or dispense volume itself.
<!-- 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>
…se more than tip liquid volume (#18844) # Overview Without the change in this PR, if an attempt is made to dispense more than the volume present in tip, an obscure error saying `'Value must be a positive float.'`. This error stems from the `dispense_and_wait` method when trying to find the correction volume for a negative volume found by calculating tip volume after dispense as `current_tip_vol - dispense_vol`. This PR adds a quick check for tip volume and raises an informative error to the user. ## Risk assessment None. Only adds an error message.
<!-- 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 Small PR to add a few final docs callouts before the 8.5 release: 1) adding a link to the [complex commands](file:///Users/emilyburghardt/opentrons/api/docs/build/html/v2/new_complex_commands.html) section of the API docs when describing for the first time how to use `transfer_with_liquid_class()`. @sanni-t pointed out that users might not know where to find this kind of detail. 2) updating our well bottom warning for [EXEC-1637](https://opentrons.atlassian.net/jira/software/c/projects/EXEC/issues/EXEC-1637?jql=project%20%3D%20%22EXEC%22%20ORDER%20BY%20created%20DESC). <!-- 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. --> http://sandbox.docs.opentrons.com/docs-callouts/v2/ both small changes build with no issues ## Changelog <!-- 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. --> Is this sufficient for [EXEC-1637](https://opentrons.atlassian.net/jira/software/c/projects/EXEC/issues/EXEC-1637?jql=project%20%3D%20%22EXEC%22%20ORDER%20BY%20created%20DESC)? @caila-marashaj and I discussed keeping this simple, including leaving it at _all reservoirs_, for extra caution. fix for this should be in 8.6. ## Risk assessment low. <!-- - 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. --> [EXEC-1637]: https://opentrons.atlassian.net/browse/EXEC-1637?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
ddcc4
approved these changes
Jul 9, 2025
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.
v8.5.0
Release 8.5 isolation branch
chore_release-8.5.0targetingrelease