Merge back 'chore_release-8.5.0' into 'chore_release-pd-8.5.0'#18473
Merged
ddcc4 merged 65 commits intochore_release-pd-8.5.0from May 31, 2025
Merged
Merge back 'chore_release-8.5.0' into 'chore_release-pd-8.5.0'#18473ddcc4 merged 65 commits intochore_release-pd-8.5.0from
ddcc4 merged 65 commits intochore_release-pd-8.5.0from
Conversation
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)
(cherry picked from commit 40fb85e)
…se() (#18326) # Overview Previously, `aspirate()` and `dispense()` only took a `rate`, which is a ratio of the pipette's default flow rate. This made it hard to specify an absolute flow rate for a single aspirate and dispense call, because the default flow rate for the pipette is often unknown. As a workaround, we could override the pipette's default flow rate like this: ``` pipette.flow_rate.aspirate = 123 ``` but that permanently alters the flow rates for the rest of the protocol. For PD code generation, we were using the hack: ``` pipette.aspirate(rate=123/pipette.flow_rate.aspirate) ``` which produces the correct value, but is ugly. For both PD code generation and our human users, this PR adds an absolute `flow_rate` argument (in uL/s) to `aspirate()` and `dispense()`. AUTH-1627 ## Test Plan and Hands on Testing Added unit tests for the new argument. I relied on existing unit tests to make sure behavior is unchanged for existing code. Added tests to make sure we error if the user specifies both `rate` and `flow_rate`. ## Risk assessment Low-ish. (cherry picked from commit 50e32e2)
This wasn't handling the return values of this method properly, now it is. (cherry picked from commit 9219014)
We were not generating location sequences for the fake PE commands we generate for the pre-2.14 pre-protocol-engine protocols, and since the app is expecting them it wouldn't show any labware. Now we generate them, because the comment about how it would be hard is just wrong (?) and everything works. Closes RQA-4181 ## testing - [x] put this on a robot - [x] upload a protocol that is pre-2.14 - [x] pre-protocol should still show the labware --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: sfoster1 <3091648+sfoster1@users.noreply.github.com> (cherry picked from commit df9ee0d)
This PR updates the Sandbox Protocol Designer deployment workflow to use GitHub OIDC for authentication instead of long-lived repository secrets. (cherry picked from commit 18349a8)
Instead of repeated code, use the shared actions. This includes caching simplification as we no longer need the anything custom. The GitHub UI allows cache deletions now. These steps have been running for months in `.github/workflows/pd-test-build-deploy.yaml` (cherry picked from commit fd91110)
# Overview
Is this a good idea??!?
`protocol_api_old/test_context.py` is an old test that monkeypatches
`aspirate()` and `dispense()` in a very particular way:
```
def fake_aspirate(
vol: Optional[float] = None,
loc: Optional[Location] = None,
rate: Optional[int] = None,
)
```
These argument names, default values, and number of arguments do not
match the current API at all. That means that to make the test pass, we
have to call `aspirate()` and `dispense()` with positional arguments
(not named arguments), and `instrument_context.py` has to avoid calling
`aspirate()`/`dispense()` with any of our new arguments that are not
available in the fake (like `push_out` or `flow_rate`).
I thought we couldn't change the test because it's enforcing some
ancient API behavior that we have to support. But @jbleon95 and
@SyntaxColoring think the whole test might be redundant now, so maybe we
can just delete it?
## Review requests
I'd like feedback from anyone who knows what `protocol_api_old` is, and
what the purpose of `protocol_api_old/test_context.py` is.
## Risk assessment
A test-only change.
(cherry picked from commit 9d7aa9f)
…rties when splitting volume for transfer (#18330) Modifies volume splitting to take into account air gap volume (and conditioning and disposal volume for multi-dispense distribute, more on that later) for initial volume splitting. This allows pipetting the max volume as an for a tip even if that volume has a non-zero air gap. (cherry picked from commit 8fa944b)
…18405) # Overview Add the `aspirate_flow_rate` and `dispense_flow_rate` absolute flow arguments to the PAPI `mix()` function. AUTH-1624 This follows the theme of adding absolute flow rate support to the `InstrumentContext` functions that previously took a `rate` ratio. PD allows you to independently specify the flow rate for the aspirate and dispense in a Mix step, but the PAPI `mix()` function previously only allowed a single `rate` argument, which is a ratio that is multiplied by the pipette's default aspirate and dispense flow rates. (PD step generation worked around this limitation by changing the pipette's default aspirate/dispense rates for every Mix step. This change will let us generate simpler code.) ## Test Plan and Hands on Testing Added unit tests. You should be able to set one or both or none of `aspirate_flow_rate` and `dispense_flow_rate`. ## Risk assessment Medium. We're changing the public API. (cherry picked from commit 6f9b158)
(cherry picked from commit df970fe)
Closes AUTH-839 # Overview - Adds the ability to create a new liquid class based on user-specified properties - Adds the ability to customize an existing liquid class based on user-specified properties ## Changelog - adds liquid class modifiers to enable custom liquid classes - adds the custom liquid class creator API - small changes to 'version' arg typing ## Risk assessment Low. Supplementary stuff. Doesn't modify existing infrastructure. (cherry picked from commit 88da5fa)
(cherry picked from commit b5cfdf4)
…18456) Closes AUTH-1654 # Overview Adds a method `LiquidHandlingPropertyByVolume.set_fixed_override()` which overrides the existing 'by volume' values with the provided value You would use this in a protocol like this- ``` water = simulated_protocol_context.define_liquid_class("water") water_props = water.get_for(pipette_50, tiprack) # Set flow rate of 20uL/sec for all volumes water_props.aspirate.flow_rate_by_volume.set_for_all_volumes(20) ``` ## Risk assessment Low-None. Very small addition to functionality that doesn't change any existing behavior. (cherry picked from commit 6e1e58d)
…y-17932', 'cherry-17937', 'cherry-17980', 'cherry-17994', 'cherry-18012', 'cherry-18016', 'cherry-18073', 'cherry-18077', 'cherry-18081', 'cherry-18142', 'cherry-18147', 'cherry-18151', 'cherry-18163', 'cherry-18171', 'cherry-18181', 'cherry-18191', 'cherry-18195', 'cherry-18203', 'cherry-18207', 'cherry-18215', 'cherry-18237', 'cherry-18249', 'cherry-18255', 'cherry-18259', 'cherry-18261', 'cherry-18266', 'cherry-18282', 'cherry-18319', 'cherry-18323', 'cherry-18326', 'cherry-18330', 'cherry-18337', 'cherry-18345', 'cherry-18383', 'cherry-18403', 'cherry-18405', 'cherry-18416', 'cherry-18449', 'cherry-18450' and 'cherry-18456' into chore_release-8.5.0
…" in chore_release-8.5.0 (#18472) This reverts commit d06a5f3. # Overview In PR #17854, @caila-marashaj deleted the `operation_volume` parameter from the call to `move_to_well()` in `aspirate_while_tracking.py`, asserting that "It was previously called with the `operation_volume` parameter. This is wrong because we need z tracking to start from where the meniscus currently is, not where it's going to be." That PR was checked into `edge`. I picked that PR into `chore_release-8.5.0`. But Caila's change somehow disappeared from `edge` entirely. The code in `edge` now **does** have the `move_to_well(operation_volume=-params.volume)` parameter. @ryanthecoder thinks Caila's change was probably deleted from `edge` by one of the mergebacks from `chore_release-8.4.0` into `edge`. Ryan says that we **do** want `move_to_well(operation_volume=-params.volume)`. So now I have to revert Caila's change in `chore_release-8.5.0`. ## Test Plan and Hands on Testing I'm taking Ryan's word for it that `move_to_well(operation_volume=-params.volume)` is correct :) But let's run the CI tests to see if everything passes. ## Risk assessment Low I hope. Ryan says that the version **with** `move_to_well(operation_volume=-params.volume)` is what we've tested and released, so we should use that.
y3rsh
approved these changes
May 30, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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.
Overview
We just cut
chore_release-8.5.0, so now we have 3 live branches:chore_release-8.5.0chore_release-pd-8.5.0edgeTo merge changes back into
edge, we should do it in this order:chore_release-8.5.0 -> chore_release-pd-8.5.0 -> edgeThis PR merges the changes from
chore_release-8.5.0 -> chore_release-pd-8.5.0.(A following PR will then merge from
chore_release-pd-8.5.0 -> edge.)The changes from this mergeback are pretty small: just some whitespace changes, plus the changes from Sanniti's PR #18456 that we cherrypicked into
chore_release-8.5.0.Test Plan and Hands on Testing
Run CI tests.