Skip to content
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 27 commits into from
Nov 22, 2024

Conversation

SyntaxColoring
Copy link
Contributor

@SyntaxColoring SyntaxColoring commented Nov 18, 2024

Overview

Another incremental mergeback of release branch changes into edge.

Test Plan and Hands on Testing

Just CI.

Changelog

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

Review requests

  • See files above.
  • If you've worked on anything else that you think might have conflicts that Git didn't catch, give them a check.

Risk assessment

Low?

mjhuff and others added 25 commits November 12, 2024 12:46
…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.
* 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]>
…updates (#16852)

Covers PLAT-602
Update new maximum height dimension of the riser and adjust stacking offset of auto sealing lid
…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.
# 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 SyntaxColoring requested review from a team as code owners November 18, 2024 22:34
@SyntaxColoring 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
Copy link
Contributor

@mjhuff mjhuff left a 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.

@SyntaxColoring SyntaxColoring merged commit 2c326c1 into edge Nov 22, 2024
89 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants