chore(release): v8.2.0 #16631
Open
chore(release): v8.2.0 #16631
+468,925
−118,222
Conversation
This file contains 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
# Overview Get these into edge ASAP! - [x] Josh reviewed the snapshots PR making sure that protocols with **X** had errors in the snapshot and **S** do not. Not much else to review. We need these in so that PRs to edge are also running against these snapshots. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: y3rsh <502770+y3rsh@users.noreply.github.com>
#16422) * feat(protocol-designer): use i18n for getBlowoutLocationOptionsForForm
# Overview Internal release notes for Internal Release 2.2.0-alpha.0. Tagging edge in the monorepo and HEADs on "main" branches of dependency repositories if necessary.
## Overview Closes EXEC-719. ## Changelog * Connect the new `PATCH /errorRecovery/settings` HTTP API so it actually affects run behavior. This closes EXEC-719. * One quirk to my implementation: This will not affect preexisting runs, *unless* you *also* do `PUT /runs/{id}/errorRecoveryPolicy`. In effect, `PUT /runs/{id}/errorRecoveryPolicy` refreshes the run's snapshot of `/errorRecovery/settings`. This is probably confusing; it would be better if `PATCH /errorRecovery/settings` immediately affected the preexisting run, or if `PUT /runs/{id}/errorRecoveryPolicy` did not have that refresh effect. I don't think this matters in practice because this button will be disabled or inaccessible in our UIs while there's an active run. Also fix a couple of nearby, unticketed bugs: * If a client gave us an empty error recovery policy, we were no-opping. Instead, we want to overwrite the current policy with the new empty one. * The logic in `error_recovery_mapping.py` was unintentionally enabling error recovery on OT-2 robots if the policy was specific enough. We want it to always be disabled on OT-2s.
# Overview closes [EXEC-734](https://opentrons.atlassian.net/browse/EXEC-734). add ungrip command and allow queuing it and executing it while door is open. ## Test Plan and Hands on Testing 1. upload a protocol that will enter ER mode. 2. open door. 3. issue an ungrip command: ``` { "data": { "commandType": "unsafe/ungripLabware", "intent": "fixit", "params": { } } } ``` 4. make sure the gripper opens its jaw. tested with dev server and the command succeeded but still need to test with an actual gripper (@SyntaxColoring thank you Max) ## Changelog 1. added an ungrip command `unsafe/ungripLabware` 2. added logic for queuing while the door is open. 3. added logic for allowing to execute while door is open. ## Review requests 1. gripper command makes sense? 2. logic changes make sense? ## Risk assessment medium. added a new command but need to make sure nothing has changed with the door saftey. [EXEC-734]: https://opentrons.atlassian.net/browse/EXEC-734?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Max Marrone <max@opentrons.com>
# Overview Removes TODOs that have been addressed or are no longer relevant. Updates outdated ones. Details in comments. ## Risk assessment None.
* fix(protocol-designer): fix issues in select pipette screen
* fix(protocol-designer): fix EditInstrumentsModal issue
We identified a simple bug with the app: it displays wonky numbers for thermocycler profile cycles:  This wouldn't repeat anything at all, what's going on? Well, it turns out that when Protocol Designer added thermocycler support, they wanted something a bit more in depth than the Python protocol API's "list of steps, number of times to repeat the cycle" format. They wanted users to be able to add single steps and cycles, in arbitrary order. To make the two styles work with the engine, we made the engine's `thermocycler/runProfile` command take a flat list of steps - any of the structure of repeated commands was removed. In the app's `CommandText` display, we then had to fix up the way we displayed profiles to remove references to a `repetitions` value that now didn't exist... and we just didn't, instead setting the `repetitions` element to just be the number of steps in the profile. Fixing this ended up being a bit involved. ## summary - ad17260 Make a new interface for the hardware controller `execute_profile` function of the thermocycler, since it's important that thermocycler cycles execute inside an asyncio worker so that they won't be interrupted by e.g. pausing. This new interface takes the PD style of protocol. It relies under the hood on the same function that actually sends stuff to the thermocycler, so there shouldn't be any functional execution changes. - 335e25a Make a new `thermocycler/runExtendedProfile` command in the protocol engine, that takes as its parameters a structured list of either steps or cycles, adhering to PD's expectations since the PAPI's expectations are a strict subset of PD. This implements its command by using the new hardware controller. - e842a2a Use the new structured data to implement a command text for the new command that can render the equivalent of what PD makes (and, again, what the PAPI does, which is a strict subset) - e842a2a Also make the old command text not use a "repetitions" keyword that doesn't exist - 0043ab7 Switch the PAPI to emitting the new command in api 2.21 ## new UI These UI changes will be on https://s3-us-west-2.amazonaws.com/opentrons-components/rqa-2771-thermocycler-extended-profiles/index.html?path=/docs/app-molecules-command-commandtext--docs for the desktop and general text and https://s3-us-west-2.amazonaws.com/opentrons-components/rqa-2771-thermocycler-extended-profiles/index.html?path=/docs/app-molecules-command-command--docs for the ODD colored-background elements whenever they upload. Here's a screenshot of what they were like when the PR was opened: `CommandText` of `thermocycler/runProfile` :  Note the change to the first line. This needs wordsmithing. `CommandText` of `thermocycler/runExtendedProfile`:  Note the two-level rendering. The common case will probably be that there's only cycles ## todo - [x] wordsmith - ~[ ] add to PD?~ no, but structured in a way that it will be easy eventually - [x] Test. Oh boy Closes RQA-2771 --------- Co-authored-by: Ed Cormany <edward.cormany@opentrons.com>
…es battery (#16430) # Overview Upgrade python and dependencies on the analysis battery test. ## Checks - [x] Works locally - [x] CI lint works - [x] CI test works
…16429) * fix(protocol-designer): fix pipette info card in protocol overview
# Overview Remove cruft from `generate_analyses.py` and analyze against `n` containers in a ThreadPoolExecutor. - [x] Works locally - [x] Works in CI
# Overview Redo logging for this API ## Test Plan and Hands on Testing - [x] local logging output in the container is JSON - [x] local logging output with local environment is text Once merged and auto-deployed to staging, we will look at the output in DataDog ## Risk assessment - medium - we are not getting what we need in DataDog to build filters and alerts and so we must evolve with this this - there is also a risk with the middleware stacking, so we will test a lot in staging
# Overview <!-- Update to automated asair sensor script --> ## Test Plan and Hands on Testing <!-- Tested on ABR units to ensure automatic discovery and connection of USB0 --> ## Changelog <!-- Connects specifically to USB0 port, in order to run properly on robots using the plate reader --> ## Review requests <!-- - ABR_Asair drivers will still work as intended for other instances where it was used -->
…late and record information regarding a protocol. (#16433) # Overview Utilizes Opentrons CLI to simulate protocols and get information including; expected change in volume, deck labware, and module usage insights. ## Test Plan and Hands on Testing Tested tool using all abr protocols in the test-protocols folder as well as self made test-protocols to verify the accuracy of the results. ## Changelog Protocol will now comment if an aspiration belongs to air gap, to indicate that the volume should not change ## Risk assessment Low risk, this protocol simulation tool is still in it's beta, and does not change overall functionality of its dependencies.
# Overview Moved to `3.13.0-rc.3` yesterday, today the stable is available in the runners. I speculate this will solve the issues with python not being mapped in https://github.com/Opentrons/opentrons/actions/runs/11243746409/job/31260344370?pr=16439
## Overview
The `GET /runs/{id}/loaded_labware_definitions` and `POST
/runs/{id}/labware_definitions` endpoints were accidentally documented
in OpenAPI as returning the *run,* not the labware definition. This
fixes that.
## Review requests
* Documented return types match actual return types?
* OK with the `SimpleBody[list[...]]` thing?
## Risk assessment
Low.
## Overview After discovering some new shapes and generally interacting with the new well geometry data structures, I think it would be better to reshape the geometry data a little bit. Rather than having each section of a well be represented by its top cross-section and top height, let's just represent a section in its entirety, with bottom and top cross-sections and bottom and top heights being present in every shape that is not a `SphericalSegment`. ## Changelog - add `RoundedRectangle` class - add `TruncatedCircle` class - add `CircularFrustum` and `RectangularFrustum` classes - adjust `frustum_helpers` and tests to use the new data structure ## TODO - We should [write some more tests](https://opentrons.atlassian.net/browse/EXEC-743?atlOrigin=eyJpIjoiYzg5OThhMjQ2NTViNDRmNGI2OTkwMWEwYTExMmFjNjIiLCJwIjoiaiJ9) to make sure invalid wells don't get passed in without an error being raised. - Implement the math for [truncated circle](https://opentrons.atlassian.net/browse/EXEC-712) calculations - Implement the math for [rounded rectangle](https://opentrons.atlassian.net/browse/EXEC-744) calculations --------- Co-authored-by: Ryan howard <ryan.howard@opentrons.com>
…#16439) # Overview Addresses a long-standing TODO to separate out the pipette movement conflict and deck-placement conflict code since they are completely exclusive of each other and don't need to be in the same file. ## Changelog - moved all pipette movement conflict checking code to `pipette_movement_conflict.py` ## Risk assessment None. Refactor only
fixes RQA-3277 <!-- 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 <!-- 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. --> I noticed that the label text next to the toggle button no longer displays on the Magnetic Module step form. This PR aims to fix that and update the form to better match the [design](https://www.figma.com/design/WbkiUyU8VhtKz0JSuIFA45/Feature%3A-Protocol-Designer-Phase-1?node-id=5536-13337&node-type=canvas&t=F8BuTfbRtt7v67rR-0). ## 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. --> - Create an OT-2 protocol and add a magnetic module GEN1 or GEN2 - Go to the Protocol Steps tab and add a step for Magnet ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> - Added an optional boolean `isLabel` prop in `ToggleExpandStepFormField` to handle displaying label text next to the toggle button when needed - Changed `magnetAction.label `from "Magnet action" to "Magnet state" in `form.json` - Remove Box component with borderBottom in `ToolBox` to get rid of double grey separation lines - Used `getInitialDeckSetup` and `getModulesOnDeckByType` to get the slot location info for displaying the icon ## 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: shiyaochen <shiyaochen@admins-MacBook-Pro.local>
Works towards RSQ-161 When we want a well set relevant to a specific pipette's interaction with a specific labware, we use a helper, getWellSetForMultichannel. This works great, but it doesn't have the ability to return relevant wells given a nozzle layout. So for example, if the pipette has a nozzle layout of "column" on a 96 channel, and the well of interest is A2, all 96-wells are returned. This PR adds support for all current nozzle layouts, which are generally utilized in the context of partial tip configs. In nozzle configurations which do not naturally incorporate the entire row/column (this is only the 8-channel column config with <8 nozzles, currently), return thewellName and the number of relevant wells "lower" than that well name. Ex, if B1 is the wellName and the active nozzle count is 4, return B1-E1. If less wells are available than the activeNozzleCount, return fewer wells.
…ads (#16397) <!-- 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 Counts Gripper Actions with `opentrons_tough_pcr_auto_sealing_lid` and increased tracking with Plate Reader ## Test Plan and Hands on Testing Ran scripts and checked results ## Changelog Added function to count number of times opentrons_tough_pcr_auto_sealing_lid lid is picked up by gripper Added functionality to record each byonoy plate read and specify read type and wavelength Error handling for google sheets interaction. ## 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. -->
# Overview This PR introduces the first version of an Opentrons liquid class schema. Single liquid class definitions will adhere to this schema and be keyed by pipette and tip type. Closes AUTH-832 ## Test Plan and Hands on Testing - Look through schema and ensure it adheres to our finalized liquid class testing matrix. Any feedback on schema structure/style is appreciated. - Try out some test data in a JSON validator. I created a base fixture that passes schema validation. We can modify that for testing. ## Changelog - create liquid class schema v1 - add fixture ## Review requests See test plan. Should we leave keys for `patternProperties` pipette and tip type less restrictive strings? Perhaps any `safeString` rather than following more stringent regex? ## Risk assessment low
`PipetteState` and `TipState` were both storing the length of the pipette's currently-attached tip. I think that duplication was accidental. The `TipState` one was only used in one place, so this deletes that in favor of the `PipetteState` one.
…anguage setting to app config (#16393) adds a config app language value to desktop/ODD and initializes i18n language to the stored app language config value. detects the user's system language in desktop app-shell and transmits to renderer via IPC/redux. adds a system language config value. closes PLAT-504, PLAT-497
Works toward EXEC-807 We have this code in the ODD that runs every render cycle on a lot of the "idle" views that manages the scrollbar. We instantiate a new observer on every render, but the old observer is never cleaned up. This commit ensures that we only ever instantiate one observer, and we properly remove it on component derender.
…plate reader lid. (#16781) - The plate reader lid hits the Flex side window when the gantry homes while the gripper holds the lid, don't do that! :) - Instead, let's update the gantry position from the encoders, so we don't have to home at all.
) Closes RABR-663 and RABR-667 During calibration flows, we currently don't have any error handling for failure to create a maintenance run. If a user exits pipette calibration and re-enters too quickly, for example, the "Move gantry to front" button is disabled indefinitely. This PR just adds some basic error handling if a maintenance run fails to be created successfully.
…g the plate reader. (#16797)
* fix(app, components) fix csv name wrapping issue
* fix(components) fix long unit wrapping issue
Closes RQA-3589 At the end of a protocol run, we execute tip detection logic to determine whether or not we should pop drop tip CTAs. There are a few network requests necessary to make this work, and we are not error handling if any of these requests fail. This PR adds a general fallback: if almost any network request fails, let's just assume both pipettes have tips attached and pop the CTAs (assuming the pipettes have ok firmware status). It's probably better to be more conservative here, and in practice, this exact scenario should occur rarely. Note that the very first request we make is to get the currently attached instruments. If this request fails, we can't do drop tip wizard, so we shouldn't show CTAs. The only workaround here would be going to design and coming up with some sort of "can't detect tips" copy. At the very least, the user can always go to drop tip wizard manually and handle tips there.
…pInPlace` during Error Recovery (#16839) Closes RQA-3591 When dropping a tip in a trash bin or waste chute, the pipette moves downwards before doing the drop tip. During Error Recovery, when we retry the failed command with a fixit intent, we need to perform a moveToCoordinates first before dispatching the dropTipInPlace or the robot drops the tip(s) from too high a location. To know how far to move, we need the failedCommand to contain retryLocation metadata. We have a pattern for this already with overpressure in place commands, so we extend the same functionality here. Co-authored-by: Max Marrone <max@opentrons.com>
…account for the new format. (#16824)
…r needs to re-home (#16853) <!-- 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 This fixes an error that happens during error recovery where the gripper needs to re-home because the error flow sends a stop request. This fixes that by adding a new state called stop, and if the firmware responds with STOPPED instead of UNHOMED then we know we can just continue on without re-homing. The gripper will still go into a UNHOMED state during the following: Labware droped Collision Estop <!-- 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. -->
Closes RQA-3589 It's insufficient to check if a run entered error recovery as the sole condition for whether or not to run the post-run drop tip wizard, because it's possible for a run to proceed through error recovery then encounter a terminal error. In these spots, we must show drop tip wizard. To fix, determine whether the run just entered error recovery (or not). If it didn't, do the tip detection logic.
…teId (#16859) Co-authored-by: Jamey Huffnagle <jamey.huffnagle@opentrons.com>
# Overview Adds a docs page and publishes API Reference entries for the Absorbance Plate Reader. Addresses RTC-488, RTC-508. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.opentrons.com/docs-plate-reader/v2/modules/absorbance_plate_reader.html) ## Changelog - Adds a new page, Absorbance Plate Reader Module, under Hardware Modules - Links to new page from Hardware Modules landing page - Adds Absorbance Plate Reader to Module Setup page - Adds H3s for modules in API Reference for easier navigation - Edits to `AbsorbanceReaderContext` docstrings in `module_contexts.py` - Cleaned up malformed note syntax _for Thermocycler_ in `module_contexts.py` - Removed nitpick rule from `conf.py` now that `AbsorbanceReaderContext` is published - 🆕 Instruct authors not to detect CSV dialect when using plate reader output as RTP. ## Review requests - Check that all descriptions are true to how the plate reader behaves. - Double check that my code simulates — I have done this once. - Do we need more information in any area, especially for CSV files? - Should we provide a sample? If so, where to put it? - ✅ Should we give more concrete guidance on parsing the CSV other than "you know how to write code, yeah"? - 🆕 Do we need to list the four `wavelengths` values that actually function on a default HW config? ## Risk assessment v low, docs only
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.
Release isolation branch for v8.2.0.
All work for 8.2.0 should base from and target this branch.