chore(release): robot stack release v8.4.0 #17882
Open
+453,758
−194,094
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
… in Transfer (#17553) re AUTH-969 <!-- 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. --> This PR adds a new page for applying liquid classes in the PD transfer step when liquid classes feature flag gets enabled. <img width="276" alt="Screenshot 2025-03-03 at 2 32 59 PM" src="https://github.com/user-attachments/assets/cfc8d936-b2cb-48c0-8230-0050e4518b25" /> I need to work on Liquid Classes form error handling in the next PR. ## 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. --> 1. Enable liquid classes feature flag 2. Add a transfer step 3. Verify that the second page shows the liquid class selection and matches the three scenarios in the [design](https://www.figma.com/design/RcHb9UdygVtyXcvDcDmnTP/Feature%3A-Liquid-Classes?node-id=1833-28746&t=yVhWi9Bix2qNEUdV-4) ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> -Created `LiquidClassesStepTools` to display the apply liquid classes setting form -Created `liquidClass` to store the selected liquid class -Updated `StepFormToolbox` to display a total of three step pages when the liquid classes feature flag is on -Modify `RadioButton` to support line-clamping for subtext -Added `getSortedLiquidClassesDefs` in shared-data utils to sort the liquid classes defs in alphabetical order based on displayName -Updated 8_5_0 migration and fixture files -Added unit tests ## 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> Co-authored-by: shiyaochen <shiyaochen@sys-MacBook-Pro.local> Co-authored-by: shiyaochen <shiyaochen@sys-macbook-pro.mynetworksettings.com> Co-authored-by: koji <kk2796@nyu.edu>
* fix(protocol-designer): change text overflow prop to word
…hon (#17674) # Overview In step generation, compound commands are implemented by reducing over curried `CommandCreator`s. E.g., dropping a tip in trash is defined as something like: ``` [ curryCommandCreator(moveToAddressableAreaForDropTip, ...), curryCommandCreator(dropTipInPlace, ...), ] ``` If we generated Python for each of the atomic commands individually, we would get something like ``` pipette.move_to(...) pipette.drop_tip(...) ``` However, in the Python API, it is more idiomatic to emit a single Python command to drop the tip into the trash. We can do that by adding a `CommandCreator` that emits the standalone Python command for dropping a tip into the trash, but we need a way to *turn off* the Python for the `moveToAddressableAreaForDropTip`/`dropTipInPlace` atomic commands. (We can't just delete those atomic commands because we still need them for JSON generation, plus they do useful error checking for us.) So this PR introduces a new variant of `curryCommandCreator` that suppresses Python from the `CommandCreator`. So the implementation would become: ``` [ curryWithoutPython(moveToAddressableAreaForDropTip, ...), curryWithoutPython(dropTipInPlace, ...), curryCommandCreator(pythonDropTipInTrashBin, ...), ] ``` This preserves the existing behavior when generating JSON, but emits only a single Python command when generating Python. AUTH-1385 ## Test Plan and Hands on Testing Added unit tests. I have also been using this in my private experimental branch for hands-on testing. ## Risk assessment Low. Python generation is behind a feature flag, and this is designed to not affect JSON generation at all.
* chore(components): add a new foldere Helix to Storybook
…yntax & pythonName (#17691) Fixes a slight bug where the syntax was wrong when we don't have a mount for the 96-channel. Additionally, the python name for the 96-channel pipette is changed to just `pipette` instead of `pipette_left` since it is mounted onto both mounts
…mandsUtil (#17705) @ddcc4 noticed an error in `movableTrashCommandsUtil` which was `prevRobotState != null && !prevRobotState.tipState.pipettes[pipetteId] ? ...` where if prev robot state is null, it was incorrectly emitting the drop tip commands. The only location where it can be null is `generateRobotStateTimeline`. so this PR refactors that to emitting the atomic commands directly and bypassing the `movableTrashCommandsUtil`
* fix(protocol-designer): filter out off deck labwares
Introduce 'TRASH' text SVG. This is a new design for PD specifically, so for now, I am adding to PD in a `HardwareOverlays` subdirectory. If we plan to utilize in our other applications moving forward, I will move to `components` Closes RQA-3993
# Overview This PR introduces some major improvements to how error handling works across Opentrons drivers to make error codes more modular and customizable. The goal is to make it easier to define error codes specific to different hardware modules (like the Flex Stacker), while keeping a shared structure for handling them. These changes make error handling more consistent and maintainable across the Opentrons driver stack. It also sets the groundwork for easily adding hardware-specific error codes for future devices without needing to rewrite the core error handling logic. ## Changelog - Introduced a `BaseErrorCode` class that acts as a foundation for defining error code enums. - Created `DefaultErrorCodes`, which covers the existing error codes we were already using. - Refactored the general error handling logic to work with this new system, making it easier to plug in hardware-specific error codes in the future. - Added new tests for the `BaseErrorCode` system, including cases for raising exceptions from both default and custom error codes. - Added a new `StackerErrorCodes` enum and a set of stacker-specific exception classes.
…eparate functions (#17694) # Overview We had a single `movableTrashCommandsUtil()` function that generated commands for air-gapping, dropping tips, dispensing, blowing out, and moving to the trash bin. In order to select which action you wanted, you passed in a string `type = ('airGap' | 'blowOut' | 'dispense' | 'dropTip' | 'moveToWell')`. This was clunky and made the program flow hard to follow. It would also make it harder to implement Python generation for these compound actions one at a time. So this PR splits each of those functionalities into its own separate function. ## Test Plan and Hands on Testing I ran the tests in `movableTrashCommandsUtil.test.ts` to confirm that each of the functions behaves exactly as before. ## Review requests I recommend viewing this diff with whitespace changes ignored: in GitHub, add `?w=1` to the URL. ## Risk assessment Low. This is a refactoring to clean up the code. There should be no change in behavior.
* fix(protocol-designer): add a missing item for release notes
… ("default") offsets (#17704)
* chore(components): hide props of style props in Storybook
…olumes larger than max volume (#17702) Changes the volume splitting logic used in the liquid class transfers so that volumes that will not fit within the max volume of the pipette are split evenly by number of iterations needed to transfer
…17976) Adds output for the simulate CLI tool when using transfer_with_liquid_class, distribute_with_liquid_class, and consolidate_with_liquid_class
…le tracking PE commands. (#18033) <!-- 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 We were passing "current_well" as the aspirate/dispense params well, which is the destination. this was messing up the path planning to the destination well. Solution is easy enough and just means taking out that argument. <!-- 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-4051 If a user cancels the run on the desktop app, there was no redirect log on the ODD if the active view was any setup view that was not the option selection menu. The redirect logic simply needs hoisting: it currently exists in the option selection menu, but should really exist in the protocol setup view orchestrator component.
At least, not anymore. --------- Co-authored-by: emilyburghardt <emily.burghardt@opentrons.com>
No functional changes - Design has decided to tweak the historical offsets table a bit: the columns are rearranged, we drop the hundredths decimal place to align with other usages of offset values, and we sort by the labware name as the primary sorting criterion.
# Overview The product name for our tip rack lids should be "Opentrons Flex Tip Rack Lid", with a space in "Tip Rack". This matches the tip rack names, the name of the Opentrons Flex 96 Tip Rack Adapter, and our general [style guidance](https://opentrons.atlassian.net/wiki/spaces/RPDO/pages/980746400/Opentrons+UX+Style+Guide) on the phrase "tip rack". ## Test Plan and Hands on Testing automated tests ## Changelog `Tiprack` -> `Tip Rack` ## Review requests Any LL ramifications of this, or should it pull from shared-data? ## Risk assessment v low
…and DispenseWhileTrackingImplementation (#18049)
<!-- 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 Updating API docs for new labware offsets/LPC _advice_ in 8.4. As Anthony and I discussed, there aren't behavior changes with `set_offset`, but rather our advice on LPC/labware offsets for users is changing. This includes more differences between Flex and OT-2. <!-- 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 sandbox: http://sandbox.docs.opentrons.com/docs-labware-offsets/v2/ <!-- 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 -updating `set_offset` API reference to include changes in 2.23. I went back and forth on this one, but ultimately the latest text we had isn't necessarily true for Flex anymore. -updating our Advanced Control section to reflect new differences between Flex and OT-2, especially _advice_ for using `set_offset` in the two types of protocols. <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests Am I doing too much? Should we let some of this advice stay app/ODD only and keep Jupyter directions in this section the same? <!-- - 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. --> low.
Woops, the toggle behavior is backwards given the copy. The "on" toggle should disable the cache and clear it.
…l Analytics (#17982) <!-- 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 Mixpanel Analytics for Thermocycler, Temperature Module, and Heatershaker ## Test Plan and Hands on Testing - Merge into alpha release and determine if analytics are recorded as expected with the ABR robots ## Changelog - Created module analytics hook to record all module actions in the app and during a protocol - Implemented hook in module slide outs, heater shaker labware set up latch toggle, and run progress meter ## 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: David Gomez <57112633+djgomez-opentrons@users.noreply.github.com>
<!-- 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 Pipette functions are done in time so lets get this into 8.4.0 so we can test internally <!-- 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. -->
this can cause a stall, as a pickup does, and like a pickup we should reset encoders afterward. since all the robot context style things ignore encoders, this causes a failure on a subsequent tip pickup move. Tested on a reproducing machine with the original problem.
## Overview We had to revert #18057 because of test failures. This is the original changes + fixes for the test failures
…d transfers (#18069) Hooks the optionally settable `starting_tip` property tip to transfer_with_liquid_class, distribute_with_liquid_class and consolidate_with_liquid_class --------- Co-authored-by: Sanniti <sanniti@opentrons.com>
These commands get a much more generic name for the release. Robots with protocols that used the old commands may display the runs with those commands as bad.
Replacing #17914 Below description from that PR. # Overview API docs update for new lids methods in API 2.23: `load_lid_stack`, `move_lid`, and lids loaded onto labware. ## Test Plan and Hands on Testing sandbox: http://sandbox.docs.opentrons.com/docs-lids-in-8.4/v2/ ## Changelog - light editing to API reference entries; including removing a TODO - Loading Labware section: updating well plate used throughout the section so we can demonstrate loading a lid onto it; adding a new "Loading Lids" subsection - Moving Labware section: new "Moving Lids" section that can grow as we add more lids, like cell culture lids, compatible with `move_lid` ## Review requests Code blocks correct? Anything missing? Do we like where new information was added? Maybe update the Auto-Sealing Lids section for the [Thermocycler module example](https://docs.opentrons.com/v2/modules/thermocycler.html)? ## Risk assessment Low. --------- Co-authored-by: emilyburghardt <emily.burghardt@opentrons.com>
## Overview This introduces a buffer so calls like `log.debug(...)` won't block when journald has a hiccup and can't consume records quickly enough. This implements one of the solutions discussed in #18034. ## Changelog Calls like `log.debug(...)` are now sent to an in-memory, global-to-the-process queue, so they will never block on I/O to journald. In the background, a worker thread moves messages from the queue to journald. There are also the "sensor logs", which have the same workaround applied to them, except it's logger->queue->`RotatingFileHandler` instead of logger->queue->journald. The ultimately emitted log records are intended to be unchanged, keeping the same syslog IDs and such that we had before.
Remove the external branding from our resin tips labware. The new names follow the format `ev_resin_tips_...`. Update the - definitions - including stacking overlaps - blocklists - test fixtures - image bindings in lablib - image bindings in app labware tab ## screenshots ### lablib     ### app         ### simulation Simulates ok with the ABR protocol after fixes (change the names, remove the soak plate) ## review - did i miss any bits
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.
v8.3.1