Chore release 8.6.0 into release #19174
Open
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
# Overview Closes 2055 Keep settings button in the settings page when we transition from the landing page. **Before** <img width="1448" alt="image" src="https://github.com/user-attachments/assets/396a7c83-26ba-48d3-9015-a5a38b39e225" /> **After** <img width="1548" alt="image" src="https://github.com/user-attachments/assets/254f0b93-3bc1-4bb0-b6bf-152ec0daacf3" /> ## Test Plan and Hands on Testing CI ## Review requests Confirm Settings icon is there at the settings page ## Risk assessment Low
## Overview Closes EXEC-1645. ## Details The `<Module>` component knows how to offset itself so it's positioned correctly relative to the deck, but in order do that, we need to remember to pass it the `targetDeckId` and `targetSlotId` props, which are optional. A util feeding a couple of deck maps was forgetting to do that, so `<Module>` fell back using default, slot-nonspecific positioning. This was too subtle of an error to be noticeable for most modules, but it is noticeable for at least the Thermocycler.
…efinitions (#18853) This deletes some dead code in module definitions. These JSON definitions had SVG graphics embedded in them via [svgson](https://github.com/elrumordelaluz/svgson). We have apparently not used these in a while; we instead favor defining SVGs in `.tsx` files instead, e.g. `components/src/hardware-sim/Module/HeaterShaker.tsx`.
# Overview This PR revises and updates Chapter 7, Software, SSH instructions. - Content reorganization: separate H2s for SSH and Jupyter Notebook (no changes to any Jupyter Notebook content, other than moving to new H2). - New instructions for hardwired SSH connections. - New instructions for assigning a static IP address. - Sections are somewhat separate, any procedural numbering restarts at 1 in each. - Unrelated suggestion in `mkdocs.yml` in a comment. Recommend setting `toc_depth: 3` to reduce nesting and visual clutter in right side TOC. See also JIRA, RTC-696 ## Test Plan and Hands on Testing The SSH instructions have been tested (multiple times) and work. ## Changelog See the overview above. ## Review requests Please give it a read and share thoughts/recommend changes. Nothing fancy in here. Just markdown. ## Risk assessment Low for documentation. --------- Co-authored-by: Ed Cormany <[email protected]>
Committing Stacker instruction manual files. # Overview This is the Stacker instruction manual. ## Test Plan and Hands on Testing Will review the text for the usual style, grammar, and the usual writing stuff. Also, check to make sure links work and images appear as expected. This doesn't have some of the recent CSS, but posting it up anyway to get started. ## Changelog No changes. This is new content. ## Review requests Nothing specific. Please review and comment. ## Risk assessment Low to medium as this is a new docs feature. Who knows what horrors may lurk within. --------- Co-authored-by: Ed Cormany <[email protected]>
… locating features (#18769) Works toward EXEC-77 and closes EXEC-1487 Adds support for the slotFootprintAsChild and slotFootprintAsParent locating features as defined in the locating features v2 proposal. Notably, this adds support for parent-child stackups that comprise of: * A parent deck item with a spring plus a child deck item on top of it (ex, a deck slot with a labware). * A parent deck item with a simple mating surface plus a child deck item on top of it (ex, the temperature module or the 96ch tip rack adapter).
…o millipore labware (#18807) <!-- 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 Added the nest 12 22ml, nest 8 22ml, and nest 24 ml labware definitions + inner geometry labware def. Added axygen 96, ibidi 384, and smc 384 inner geometry labware defs. <!-- 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 Validated the labware definitions using the manufacturer drawings + calipers. Tested labware definition with lld-test-liquid-height-3mm protocol, verified volumes to be within the acceptable 3mm from bottom and 3mm from top ranges. Validated the inner labware definitions using the same protocol, calculating the height using the robot api. Verified volumes to be within the acceptable ranges for top and bottom. <!-- 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: ABR <[email protected]> Co-authored-by: Rhyann Clarke <[email protected]>
… prepare for labware schema 3 (#18885)
#18888) This file has grown to hold more than just simple compatibility shims for converting between labware schemas 2 and 3. It now also holds actual business-domain math for computing labware and module positions. Rename it accordingly.
… as incompatible with OT-2 (#18873) ## Overview This makes some small, academic corrections to module definitions. I doubt this actually affects anything user-facing, but if the data is there, it ought to be correct. ## Changelog * Mark `flexStackerModuleV1` as incompatible with the OT-2 in its module definition. * Delete some OT-2 specific transforms from `flexStackerModuleV1`. They weren't doing anything because that module can't be placed on an OT-2 deck anyway. * Mark `absorbanceReaderV1` as incompatible with `ot2_standard` *and* `ot2_short_trash`, not just `ot2_standard`.
This PR enforces that a user enter a valid disposal volume in a transfer form with 1) "distribute" path, and 2) disposal volume checked. Closes RQA-4355
Helps with EXEC-1647 # Overview It's been observed that moving lids with a gripper (specifically the Greiner labware lids) to labware on H/S is more reliable when the labware itself is latched and doesn't have any room to wiggle on the H/S- specifically when placed on a universal adapter. So we should allow lids to be placed on H/S labware with the labware latched. ## Risk assessment Low- medium. This change will allow any labware categorized as a lid to be placed on H/S (either directly or on a stack of adpater/labware(s)) without doing a labware latch check. This puts the onus on the user to make sure to leave the latch closed for the lids. Which is not too much of a responsibility and has no dire consequences in reality even if the latch stays open. We also plan on testing whether we need to add any other restrictions to improve the user experience.
* feat(app): remove 2 track events
* feat(app): update submerge and retract screen to align with pd
…18901) * feat(opentrons-ai-client): remove GlobalStyle with styled-components
* fix(app): update delay screen to align with the design
…rate, plot, and validate baselines and measurements + related improvements. (#18875)
…#18906) * fix(opentrons-ai-client): fix global style unexpected overwrite issue
<!-- 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 Flex Stacker Stamping Protocol ## Test Plan and Hands on Testing - Run with PVT stackers before 8.6 release ## Changelog - Protocol loads 1 stacker with tips and the remaining with labware - The protocol unloads labware and transfers liquid to them using liquid class behavior - Then the protocol stores the labware back into the stacker and moves on to the next set of plates ## 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. -->
* feat(app): update pushout screen
* fix(app): fix change tip frequency display in summary screen
…osystemsmicroamp_384_wellplate_40ul (#19159) <!-- 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 Adds gripHeightFromLabwareBottom offset to `appliedbiosystemsmicroamp_384_wellplate_40ul` ## Test Plan and Hands on Testing - Tested new offset on labware in robot and moved it x6 times between 2 deck slots. This resulted in no stalls. ## Changelog - Added gripHeightFromLabwareBottom to definition. This distance puts the gripper pads above the labware skirt and below the top of the labware.  
…c design's normal (#19162) * chore(opentrons-ai-client): update file structure to aling with atomic design's normal
… confirm if hopper is not empty (#19148) # Overview This PR implements a re-routing mechanism for the `flexStackerLabwareRetrieveFailed` error (or `STACKER_HOPPER_OR_SHUTTLE_EMPTY` for the frontend). # Changelog * change getErrorKind function to return `STACKER_HOPPER_OR_SHUTTLE_EMPTY` for the retrieve failed error * add `STACKER_HOPPER_OR_SHUTTLE_EMPTY` as a route with one single step `SELECT_FLOW` * add a screen for the `SELECT_FLOW` step to allow users to choose between two scenarios: "Stacker is empty" or "Stacker latch is jammed", which then routes to appropriate existing recovery flows * modify `SelectRecoveryOptionHome` function so we're automatically proceeding with the route if there's only one option
Add logic to `useAspirateSettingsConfig` and `useDispenseSettingsConfig` hooks to appropriately check if source/destination is compatible with touch tip. Refactors this check to a util.
# Overview Removing the `index.html` page from our Sphinx docs build. This page only served as a redirect to `docs.opentrons.com/v2`. Once we launch our mkdocs site, it will provide an index page that serves as a portal to all our docs publications. ## Test Plan and Hands on Testing - My first commit on this branch still included `api/docs/dist/index.html` so that got synced to the sandbox. - Subsequent commit removed it, but our sync isn't deleting files. So it remained. - Created a new branch `docs-remove-redirect-new` that has identical commits to this one and ran the API docs action. It has no index.html page and the rest of the site (within `v2/`) looks correct. <img width="2438" height="1010" alt="Screenshot 2025-08-05 at 12 02 11 PM" src="https://github.com/user-attachments/assets/59bedf7e-238f-49a1-8728-716c75d49ce7" />  I'm guessing this means we should change the sync behavior? We need to make sure that it is scoped to only `v1/`, `v2/`, `ot1/`, and `hardware/` so it doesn't clobber mkdocs sites synced by other actions. ## Changelog Remove a couple files. ## Review requests Seems right? ## Risk assessment pretty low
#19165) # Overview Ensure scroll to bottom of scrollable basics selection container on any form change (useful for small or highly zoomed in screens)' Closes RQA-4507 https://github.com/user-attachments/assets/bb2b9acb-f0ab-4f01-9936-2f1ca61b13f2 ## Test Plan and Hands on Testing - start PD onboarding and land on Step 1: Basics - shrink your window and/or zoom in such that the wizard body is scrollable - begin selecting your robot type and other fields - verify that with each form change, you are auto-scrolled to the bottom of the wizard body, to ensure the next selection is visible ## Changelog - add empty `div` to bottom of container for scrolling - add `robotType` to `useEffect` dependency array ## Review requests see test plan ## Risk assessment low
# Overview Rename Protocol Designer manual pages to improve the site map. ## Test Plan and Hands on Testing [Sandbox](http://sandbox.docs.s3-website.us-east-2.amazonaws.com/docs-pd-manual-rename/protocol-designer/) ## Changelog - Implement this site map: ``` protocol-designer/ about/ create-protocol/ robots-instruments/ modules-fixtures/ metadata-overview/ starting-deck/ steps/ transfer/ mix/ move/ module/ magnet/ pause/ edit-steps/ warnings-errors/ export-protocol/ modify-protocol/ ``` - Adds the PD manual to the main nav - Adds titles and H1s to all PD manual pages ## Review requests All the pages and images and text where we expect? ## Risk assessment low-med, could have broken some references
#19061) # Overview This PR refactors the way the Python API tracks where a tip has been picked up from. Previously we were relying on the `InstrumentContext._last_tip_picked_up_from` to keep track of which tip rack well the current tip was picked up from, mostly for the purposes of storing it for `return_tip`. The issue with this approach is that anything that did not go through the top level instrument context, whether it is via the cores or directly in protocol engine, would lead to this not being updated and lead to either incorrect behavior for tip returns or an error. This became more acute with the introduction of liquid classes and allowing them to return tips and keep them at the end, as this variable wasn't getting updated and we had to manually code around that. Now the tracking of the last tip rack well has been moved entirely to the engine, where it will store it as a combination of `labware_id` and `well_name`. This is then reconstructed into a `LabwareCore` and `WellCore` by the `InstrumentCore`, which is further reconstructed into a `Well` object by the top level `InstrumentContext`. This allowed a lot of the liquid class scaffolding around this issue to be removed and those methods to be simplified. This change also required adding this functionality to the legacy core. With no engine, in those older cores we are now simply storing the legacy labware and well cores when a pick up tip or drop tip is called, allowing this new method to work via both intefaces. Because it was discovered a lot of older protocols rely on `_last_tip_picked_up_from`, a property of the same name was added that uses the new interface. In addition, a version gated `current_tip_source_well()` function was added to provide a version-protected method that should now be used instead. ## Test Plan and Hands on Testing Snapshots and integration tests should cover a lot of the regression testing, but the following protocols will be tested: ``` requirements = { "robotType": "Flex", "apiLevel": "2.25" } metadata = { "protocolName":'Return tip new', 'author':'Jeremy' } def run(protocol_context): tiprack = protocol_context.load_labware("opentrons_flex_96_tiprack_200ul", "C2") trash = protocol_context.load_trash_bin('A3') pipette_1k = protocol_context.load_instrument("flex_1channel_1000", "right", tip_racks=[tiprack]) nest_plate = protocol_context.load_labware("nest_96_wellplate_2ml_deep", "D1") arma_plate = protocol_context.load_labware("armadillo_96_wellplate_200ul_pcr_full_skirt", "D3") pipette_1k.pick_up_tip() pipette_1k.return_tip() water_class = protocol_context.get_liquid_class("water") pipette_1k.transfer_with_liquid_class( liquid_class=water_class, volume=200, source=nest_plate.wells()[:4], dest=arma_plate.wells()[:4], new_tip="always", trash_location=trash, return_tip=True, ) pipette_1k.transfer_with_liquid_class( liquid_class=water_class, volume=200, source=nest_plate.wells()[0], dest=arma_plate.wells()[0], new_tip="once", trash_location=trash, keep_last_tip=True ) pipette_1k.return_tip() ``` ``` requirements = { "robotType": "OT-2", "apiLevel": "2.13" } metadata = { "protocolName":'Return tip OT-2 2.13', 'author':'Jeremy' } def run(protocol_context): p300rack = protocol_context.load_labware('opentrons_96_tiprack_300ul', 1) p300 = protocol_context.load_instrument('p300_single_gen2', 'left', tip_racks=[p300rack]) p300.pick_up_tip() p300.return_tip() ``` ## Changelog - Refactored `_last_tip_picked_up_from` to use engine and cores to keep track of tip, not the instrument context ## Review requests Does the way we reconstruct the `Well` object make sense? ## Risk assessment Medium/high, this refactor touches a lot of long existing methods and is not gated by version. There's no new logic added but this affects not only Flex run code but OT-2 older API versions as well. --------- Co-authored-by: David Chau <[email protected]>
neo-jesse
added
the
DO NOT MERGE
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release #19174 +/- ##
============================================
- Coverage 61.30% 24.06% -37.25%
============================================
Files 3264 3377 +113
Lines 283414 296971 +13557
Branches 36337 31523 -4814
============================================
- Hits 173759 71476 -102283
- Misses 109469 225477 +116008
+ Partials 186 18 -168
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
# Overview Replacing Josh's placeholder with the 8.6.0 alpha release notes. ## Test Plan and Hands on Testing ## Risk assessment low.
* fix(app): fix tip drop location display in overview tab
…sions (#19181) Cherry picked from commit e5b41f7 / PR #19126. Co-authored-by: Rhyann Clarke <[email protected]>
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 branch for 8.6.0