-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(release): v8.2.0 #16631
Open
y3rsh
wants to merge
547
commits into
release
Choose a base branch
from
chore_release-8.2.0
base: release
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
chore(release): v8.2.0 #16631
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
…#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
* fix(components): fix disabled button style in PD
* feat(components): add two icons for PD
* fix(protocol-designer): remove # from version text
…lect pipette screen (#16464) * fix(protocol-designer): remove opentrons phrase from checkboxes in select pipette screen
* refactor(protocol-designer): export metadata as a component
#16465) * fix(protocol-designer): fix snackbar display issue in select a pipette
…EditInstrumentsModal (#16438) * fix(protocol-designer): fix pipette type button display condition in EditInstrumentsModal
Closes EXEC-760 The loadPipette command is important for executing commands associated with a specific pipette, but it also resets internal state, which can leads to bugs like the ones in the linked ticket. If the pipette has been loaded earlier (ie, during error recovery, synonymous with fixit command flows), we should not load the pipette. We still load the pipette during maintenance runs (drop tip wizard when not in error recovery).
# Overview Wrap second `ProtocolOverview` column once minimum page width is hit Closes AUTH-716
…mponent (#16432) * fix(protocol-designer): update Step part design and export it as a component
Closes RSQ-161 This PR adds partial tip support during Error Recovery flows, specifically for tip pick-up during overpressure error recovery. After talks with design, users will be unable to select wells themselves if using a partial tip layout, since this helps prevents unexpected pickups. There are some special-cased copy updates, too.
Closes EXEC-765 Adds an option for toggling error recovery. If ER mode is disabled, the run fails instead of entering recovery mode.
…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
…16884) Closes RQA-3583 Currently, the app inspects an errorType on a failed drop tip command to determine whether to throw the special case "home the gantry" error modal. Recently, the error type changed for failed update estimator commands, so the special modal was broken. Instead of special-casing the errorType for failed estimator commands, let's just assume that any failed estimator command is caused by an unknown position error and pop the special modal. Note that this also handles any error in the same manner with a "MustHomeError" errorType, too.
# Overview Known issue for downgrading below 8.2 with a plate reader attached. ## Test Plan and Hands on Testing Check in next alpha. ## Changelog Single bullet in API release notes. ## Review requests - Does this capture the issue properly? Is there a related app-side issue? - Do we need to mention the problem of downgrading a robot _on the same network_ as a plate reader? ## Risk assessment nil
# Overview Prettier (or whatever runs in our JS lint action) demands a newline after a markdown header. OK. ## Test Plan and Hands on Testing Pass automated tests plz. ## Changelog `\n` ## Review requests Forgive this shameful and time-wasting PR. ## Risk assessment none
…id_auto_seal_lid to release (#16903) Covers RABR-669 Adds compatibility between `biorad_96_wellplate_200ul_pcr` and `opentrons_tough_pcr_auto_sealing_lid` with stacking z offset
Closes RABR-672
Closes RQA-3645 Recent gripper firmware changes add new degrees of G axis "home" state, and this ultimately causes the unsafe/ungripLabware command to fail, since a successful completion of the ungrip does not set the HOME flag. Because we ultimately want to ungrip the labware AND home the gripper G axis, let's use a parameterized home command instead.
* fix(components): fix unit text wrap-issue
…losed (#16941) Covers RABR-674 Raises an error during analysis when the plate reader lid is not closed and a read is attempted.
…e recovery policies during a run (#16950) Closes RQA-3670 We need to support the client ignoring several different classes of errors in a single run, which means the app needs to know the current recovery policy and be able to modify. This PR adds the necessary infrastructure to support that. Co-authored-by: Max Marrone <max@opentrons.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
DO NOT MERGE
Indicates a PR should not be merged, even if there's a shiny green merge button available
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.