feat(protocol-designer): bring back deck setup drag & drop #17477
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
## Overview This PR is the rebased version of #17141
opentrons_simulate tries to see if any json file it can reach is a labware and load it if so. We recently changed the exceptions we raise in verify_labware_definitions if that call fails, so now instead of ignoring the file on exception opentrons_simulate raises the error through and terminates. No good! Change the exception to something a little saner and make sure we can actually ignore invalid labware files in sim. Closes RQA-3820
We pipe errors from nmcli straight to the display when we get them. NMCLI has famously awful errors. We don't want to always squash them, because they could be useful, but in the case of a mis-entered WPA2 PSK, we can be pretty sure that's the problem. This will now say "check your wifi credentials" <img width="607" alt="Screenshot 2025-01-07 at 4 46 15 PM" src="https://github.com/user-attachments/assets/d9006f01-37e8-4221-812a-900ffcb61960" /> ## Testing - [x] Connect to a wifi network and purposefully enter the wrong password; you should get a less awful message. Note that this only actually works if you're disconnected from wifi when you try to connect; if you're connected to wifi and then try and connect to a network and use the wrong password, you just don't get a result because the request went out over the original wifi network which got disconnected. It's the same code on the flex, ot-2 on the desktop (the ODD has a different message). Closes RSQ-3
Fix a flaky test by running filesystem commands sequentially instead of in parallel.
This is very odd and I'm not sure when it would have changed but this is the thing the error message says to do. ## Testing - [x] does the apple build work - [x] does the apple build run
…rotocol (#17216) <!-- 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're doing a direct "load_definintion" call in this protocol so we need to update it to have the new OEM arg added in 8.3 <!-- 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. -->
Came up for PD ( #17229 ), probably will come up here too. Let's get ahead of it. If the build passes this should be fine.
… can errors (#17117) <!-- 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 occasionally get some ABR issues where the can bus says it's not receiving ACKs or that a move group says it didn't get all expected nodes, but reports [] as the missing nodes. I think the second bug is because we're checking with `if not self._moves[group_id]` instead of checking `if len(self._moves[group_id]) == 0:` Which should be equivalent but I think there may be some python cleanup bug that reports the list as true due to a remnant that hasn't been garbage collected yet. <!-- 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. -->
…ed (#17264) robot-server sometimes stores, in its database, run commands that do not have a `result`. For example, if a command failed, it has an `error` instead of a `result`. After the recent Pydantic v1->v2 upgrade, parsing these commands was broken for about 1/3rd of our command types. The server would raise a 500 error. Their Pydantic models were defined like: ``` result: Optional[FooResult] ``` In Pydantic v1, that parses JSON where `result` is `null` or omitted, but in Pydantic v2, it only parses JSON where `result` is `null`. We need to change it to: ``` result: Optional[FooResult] = None ```
This is used by the client to decide whether something is a lot when it's rendering destinations, and if this doesn't exist then intervention modals will show the labware moving off deck. Closes RQA-3839
…ction (#17316) This commit brings the `lastRunCommandPromptedErrorRecovery` util back and adds the new and improved behavior to also check if Error Recovery is enabled (in settings). If it's not enabled, we need to run tip detection even if the last run command was recoverable.
- the takeover modal for maintenance runs (RQA-3868) - run start confirmation (not tagged yet) - run cancel confirmation (RQA-3869) Closes RQA-3868 Closes RQA-3869 <img width="1046" alt="Screenshot 2025-01-17 at 4 58 05 PM" src="https://github.com/user-attachments/assets/66d00f4a-5e49-4f34-8049-ae74051f710e" /> <img width="1037" alt="Screenshot 2025-01-17 at 4 58 40 PM" src="https://github.com/user-attachments/assets/b39ef8b7-77aa-4cfe-8452-e447e439460b" /> <img width="1035" alt="Screenshot 2025-01-17 at 5 05 22 PM" src="https://github.com/user-attachments/assets/ffb47a09-0f02-4b26-b4e4-54fa43d7865c" />
… and refactor the schema to catch the error (#17501)
…s on the Flex Stacker. (#17478) - Adds support for interfacing with the TMF8820/21/28 dToF (direct Time Of Flight) sensors for the Flex Stacker. - Adds the following GCodes and implementations to the flex stacker driver M215 - Get TOF Sensor Status M222 - Get TOF Driver Register M223 - Set TOF Driver Register M224 - Enable TOF Driver
<!-- 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 apilevel to 2.22 in docs (versioning page and apilevel substitution) <!-- 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. --> sandbox http://sandbox.docs.opentrons.com/docs-apilevel-2.22/v2/ ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> -updated `versioning.rst` to include the latest software (8.3.0) -updated `conf.py` to change the `|apiLevel|` substitution to 2.22 ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> Quick check to make sure this looks OK. ## 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. --> very low
Adds engine core implementation for `consolidate_liquid` for use with liquid classes
jerader
removed
the
DO NOT MERGE
Allow moving a labware (labware-bottom) with another labware
(labware-top) on top of it, as long as labware-top is labware-bottom's
lid by its lid id.
## Testing
- [x] try and move a tiprack that has a lid on it
```
metadata = {
"protocolName": "Move tiprack with lid",
}
requirements = {
"robotType": "OT-3",
"apiLevel": "2.23",
}
def run(protocol):
trash = protocol.load_trash_bin(location="A3")
plate = protocol.load_labware("armadillo_96_wellplate_200ul_pcr_full_skirt", "C1")
tiprack = protocol.load_labware(
"opentrons_flex_96_tiprack_1000ul", "D1", lid="opentrons_flex_tiprack_lid"
)
adapter = protocol.load_adapter("opentrons_flex_96_tiprack_adapter", "D2")
p1000 = protocol.load_instrument("flex_96channel_1000", "left", tip_racks=[tiprack])
protocol.move_labware(tiprack, adapter, use_gripper=True)
protocol.move_lid(tiprack, trash, use_gripper=True)
p1000.pick_up_tip()
p1000.aspirate(200, plate["A1"])
p1000.dispense(200, plate["A1"])
p1000.drop_tip()
```
Closes EXEC-1116
…otocol (#17475) <!-- 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 Low Volume 96ch pipette protocol ## Test Plan and Hands on Testing - tested protocols on robots ## Changelog Added 3 protocols - 2 96ch low volume ones at api 2.23 - corrected some error recording issues with retrieving protocol files - created protocol to fill all plates for robots with a 96ch ## Review requests @sfoster1 I have noticed that the robots will have their protocol files saved in different numbered folders with opentrons-robot-server. How can I get this scrip to iterate these folders to find the file that matches the protocol_id? ## 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. -->
ncdiehl11
reviewed
Feb 14, 2025
There was a problem hiding this comment.
Looks good! i think we should add BlockedSlot logic for blocking fixtures (like trash bin/wastechute). Also, can we transform the labware drag preview shadow such that the cursor is more accurate? The drag is a bit misleading because the drag preview shows the labware landing on a different slot than intended
@ncdiehl11 , oh ya, good suggestion! i didn't think of that. thanks!
ooops ya, let me see what i can do. thanks! |
ncdiehl11
reviewed
Feb 14, 2025
protocol-designer/src/pages/Designer/DeckSetup/Overlays/AdapterControls.tsx
Outdated
Show resolved
Hide resolved
protocol-designer/src/pages/Designer/DeckSetup/Overlays/AdapterControls.tsx
Show resolved
Hide resolved
|
ticket to address the drag preview being too far above the cursor: https://opentrons.atlassian.net/browse/AUTH-1469, will address it when i'm back from PTO |
ncdiehl11
approved these changes
Feb 14, 2025
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.
closes AUTH-1276
Overview
NOTE: the commit history is messed up because for some reason i merged edge into this branch when its targetting the PD release branch. But i reverted that commit and file changes are correct
This PR brings back drag/drop to deck setup with the same functionality as it had in the pre-redesign. You can only drag top-level labware and can not drag: modules or adapters. When we add stacking capabilities, we will need to refactor it to account for that level of stacking.
Test Plan and Hands on Testing
Test that you can drag and drop any labware to any slot on the deck (minus trash bins/waste chutes). If the labware is not allowed to that slot, you should see the warning
blockedSlotlabel indicating that you can't drop it there.Changelog
LabwareControls,AdapterControls, andSlotControlsfor the deck map andDeckItemHoveris now refactored intoOffDeckControlssince its used only for off deck. The reason why they needed to each have their own is because the react dnd considerations are different for eachDragPreviewwhich is responsible for the lighter container when you are actively dragging something aroundRobotCoordinateSpaceWithRefto returngetRobotCoordsFromDOMCoordswhich is used inDragPreviewto determine the DOM coordinatesDeckSetupDetailsto accommodate those new controlsgetSwapBlockedto be used for labware<>module compatibilitymoveLabwareFormErrorsto also use the new labware<>adapter compatibility methodRisk assessment
mid- affected deck setup and is the bulk of the 8.4.1 release