Chore release 8.7.0 into release #19519
Open
+24,748
−1,553
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 Add images for corresponding new labware. ## Test Plan and Hands on Testing Built labware-library and confirmed that added images are present and correspond to the correct labware load_name Closes AUTH-2231
…ck up axygen_96_wellplate_500ul change (#19372)
# Overview Changed nest 12 well 22 ml image to be a smaller size and clearer image. # Testing Spot checked on labware-library
…19408) Adds a `version` argument to the public `ProtocolContext.get_liquid_class` method.
The lid geometry got slightly changed to avoid a too-close fits with plates that caused them to vacuum seal to the underlying labware. Closes EXEC-1781 ## Testing - Run a protocol that: - [x] stacks on `opentrons_96_wellplate_200ul_pcr_full_skirt` - [x] stacks on itself - [x] stacks on reservoirs
…dapters and lids (#19348) ## Overview Closes the Python part of EXEC-1750. The Python Protocol API has a number of "combination load methods" that let you load multiple labware in a single call, like a main labware plus an adapter, or a main labware plus a lid. * `Labware` * `load_labware()` * `ModuleContext` * `load_labware()` * `set_stored_labware()` * `ProtocolContext` * `load_labware()` * `load_lid_stack()` There are two things about these APIs today that are problematic: 1. There are no parameters to let you manually specify the namespace and version of the adapter/lid, like you can for the main labware. 2. Without those parameters, the Python Protocol API tries to automatically pick the namespace and version values for the adapter/lid. The specific way that it does this is problematic. It will sometimes try to match the the version of the adapter/lid to the version of the main labware. But there's no reason to believe that that version of the adapter/lid will even exist. For example, you could have a well plate that goes up to v5 and a lid that only goes up to v2. ## Changelog For all of the "combined load methods": * Add new parameters: * `lid_namespace` * `lid_version` * `adapter_namespace` * `adapter_version` * In the case where these parameters are not supplied, stop copying their values from the namespace and version of the "main" labware. Instead:`namespace` defaults to searching `opentrons` and custom labware, and `version` defaults to something `apiLevel`-dependent. This is consistent with how the basic case of `ProtocolContext.load_labware(load_name, location)` works. * Gate this behind ~~`"apiLevel": "2.25"`, which is the `apiLevel` being released in robot software v8.6.0.~~, `"apiLevel": "2.26"`, which is the next one in line to be released. * Update docstrings enough to be correct, though perhaps not enough to be good. I'll leave refinements to follow-up PRs.
# Overview Now that we have versioning support in `get_liquid_class()` (PR #19408), this PR takes the updated liquid class values for `water` (PR #19141) and makes them available as version 2 of the `water` class. AUTH-2246 This PR also makes the preliminary values for the low-volume 96 `flex_96channel_200` pipette available in `water` v2, so that they can be used by hardware testing. If we decide that we don't want to release `flex_96channel_200` in the public RS 8.6.1 release, we'll delete the `flex_96channel_200` values again. And this fixes the `test_gravimetric_protocol.py` test to stop failing. It's been failing since PR #19306 when we deleted the `flex_96channel_200` liquid class values from RS 8.6.0. ## Test Plan and Hands on Testing Ran the updated `test_gravimetric_protocol.py` and confirmed that it passes. Confirmed that `test_protocol_core.py` still passes. ## Risk assessment Low. But remember to remove the `flex_96channel_200` values from `water` v2 if we don't want to release them.
We have a nice image, we have nice geometry, let's show them off Closes EXEC-1696
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release #19519 +/- ##
===========================================
- Coverage 24.67% 23.86% -0.81%
===========================================
Files 3381 3390 +9
Lines 298379 299304 +925
Branches 31513 31806 +293
===========================================
- Hits 73627 71436 -2191
- Misses 224736 227851 +3115
- Partials 16 17 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
…Stacker based on the rear-panel revision. (#19508)
When we move labware during the gripper, we use the position of the labware jaw while labware is nominally gripped to determine whether we successfully grabbed the labware or not. We compare the position to some fact of the labware's geometry. Because the geometry doesn't actually contain the width at the point that it's gripped (it only has the bounding box, which includes e.g. a skirt that the gripper doesn't interact with) and because the gripper's jaw width position tracking can have problems, we also allow uncertainty. There were a couple problems that are now fixed, such as - We were doing an exact position comparison for the gripper-fully-closed case; this is not really safe because the encoder can be a little off, so add a less-than check to make sure we detect it - The big one: we determined our uncertainty values by the difference between the well bounding box and the labware bounding box. For labware that doesn't have wells, that means the uncertainty is effectively infinite. Instead, use a fixed distance. - Also, refactor some stuff to support it. The behavior for things that have wells should be unchanged. ## testing - see if we can detect failed lid pickups now! Closes EXEC-1783
It's not called Q it's called axis96ChannelCam, and also it needs to be in some other types. Closes RQA-4571
…null (#19631) # Overview I have not been able to reproduce these PD crashes reported in Sentry: - https://opentrons-76.sentry.io/issues/6867128274/?project=4509363266387968 - https://opentrons-76.sentry.io/issues/6867128191/?project=4509363266387968 But from the stack trace, they seem to be happening because we're calling `volumeTooHigh()` with a null `tipRack` from the form, which in turn calls `getPipetteCapacity()` and `getTiprackVolume()`, where we crash. Note we previously fixed the crash in `volumeTooHigh()` caused by `pipette` being null (PR #19353), so we can fix the crash caused by `tipRack` being null in the same way. ## Test Plan and Hands on Testing Smoke tested PD running locally. ## Risk assessment Low.
…tate after liquid class transfers (#19595) Fixes a long-standing bug in the Python API code, where default flow rates would not correctly update in response to different capacity tips being picked up or volume mode being changed, and configure_for_volume wasn't resetting flow rates as the documentation claimed.
<!-- 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 adding PD 8.5.4 release notes; includes a few bug fixes. <!-- 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 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. -->
Resolved conflicts: - protocol-designer/src/step-forms/reducers/index.ts
<!-- 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 adding 8.7.0 alpha release notes. <!-- 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 few specific asks in comments! <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## 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. -->
Correctly handle null form values for `aspirate/dispense_mmFromBottom` fields in moveLiquid form and `mix_mmFromBottom` field in mix form.
* fix(app): fix blowout flow rate value in generated qt
…ted in distribute (#19627) This PR fixes a bug in JSON step generation in which disposal and conditioning volumes were not correctly aspirated with the sample volume.
* fix(app): fix disposal volume issues
* fix(app): fix 96 channel 200ul case
# Overview The updated gripper failure check did break the absorbance reader movement check. This PR adds a labware quirk that makes the check revert back to the legacy check.
…esponseSerial one. (#19679)
#19709) * fix(protocol-designer): fix wastechute and trashbin check for dispense
<!-- 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. --> ## 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. -->
…er namespace/version (#19717) ## Overview This fixes a backwards compatibility bug in my implementation of #19348 / EXEC-1750. ## Details #19348 did two things, in various places: 1. It added new params * `adapter_namespace` * `adapter_version` * `lid_namespace` * `lid_version` 2. It adjusted the behavior when those params were omitted In one of those places, I forgot: * to raise an error if you tried using the new params on an older `apiLevel`s * to preserve the old behavior when the params were omitted This PR adds that backwards-compatibility behavior, following the pattern from the rest of #19348. This is targeting `chore_release-8.7.0`. v8.7.0 is the first robot software release that would have the changes from #19348.
# Overview Change MILLIPLEX lid and plate display name ## Test Plan and Hands on Testing Simulated labware-library to confirm display change <img width="422" height="354" alt="Screenshot 2025-10-06 at 1 15 56 PM" src="https://github.com/user-attachments/assets/23bff866-56d3-4b6a-aee0-d4ff76e3e17e" /> <img width="422" height="348" alt="Screenshot 2025-10-06 at 1 16 08 PM" src="https://github.com/user-attachments/assets/f9d36afc-46aa-4f56-bfea-cb7fbd161fee" /> Simulated this protocol to confirm stacking with compatible labware was still functional ``` """Test labware definition .""" from opentrons.protocol_api import ProtocolContext from opentrons.protocol_api.module_contexts import HeaterShakerContext metadata = { "protocolName": "labware definition checker ", "author": "Opentrons <[email protected]>", "source": "Protocol Library", } requirements = {"robotType": "Flex", "apiLevel": "2.26"} def run(protocol: ProtocolContext) -> None: """Protocol.""" # Lid loading lid = protocol.load_lid_stack("black_96_well_microtiter_plate_lid", "C1", 1) labware = protocol.load_labware("milliplex_r_96_well_microtiter_plate", "D3") # pick up tip hsh: HeaterShakerContext = protocol.load_module( "heaterShakerModuleV1", "D1" ) # type: ignore[assignment] adapter = hsh.load_adapter("opentrons_universal_flat_adapter_type_b") hsh.open_labware_latch() protocol.move_labware(labware, adapter, use_gripper = True) hsh.close_labware_latch() protocol.move_lid(lid, labware, use_gripper = True) ``` ## Changelog - LID: changed display name, load name, brand, and image file name - Plate: changed display name, load name, and image file name - updated `constants.ts` ## Risk assessment Low Closes EXEC-1940 Closes EXEC-1941
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.
8.7.0