-
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): Merge chore_release-8.2.0
into edge
#16879
Merged
Merged
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
…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 <[email protected]>
…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 <[email protected]>
# 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
Resolve conflicts in: * api/src/opentrons/protocol_engine/commands/aspirate_in_place.py * api/src/opentrons/protocol_engine/commands/dispense_in_place.py * api/src/opentrons/protocol_engine/commands/drop_tip_in_place.py * api/src/opentrons/protocol_engine/commands/pipetting_common.py * api/src/opentrons/protocol_engine/errors/__init__.py * components/src/atoms/InputField/index.tsx * components/src/atoms/buttons/RadioButton.tsx * robot-server/robot_server/runs/router/base_router.py
SyntaxColoring
requested review from
shlokamin
and removed request for
a team
November 18, 2024 22:34
Resolve conflicts in: * api/src/opentrons/hardware_control/ot3api.py * api/src/opentrons/protocol_engine/commands/drop_tip.py
SyntaxColoring
force-pushed
the
merge_release_820_into_edge
branch
from
November 22, 2024 14:51
aaffc39
to
2c326c1
Compare
mjhuff
approved these changes
Nov 22, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! App conflicts seem correct and the api changes seem reasonable.
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.
Overview
Another incremental mergeback of release branch changes into
edge
.Test Plan and Hands on Testing
Just CI.
Changelog
Resolve conflicts in:
Review requests
Risk assessment
Low?