Partial tip smoke test #15689
Closed
Partial tip smoke test #15689
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
DerekMaggio
force-pushed
the
partial_tip_smoke_test
branch
from
cde5a51
to
5d4352e
Compare
DerekMaggio
force-pushed
the
partial_tip_smoke_test
branch
3 times, most recently
from
f9f237e
to
d63850f
Compare
re AUTH-591 <!-- 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. --> Send and save the CSV RTPs used in protocol runs to the new table created in the database, and hook it up to the GET endpoint that fetches all the data files used in analysis and run. ## 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. --> - run test files to ensure that csv rtps get insert to the new run_csv_rtp_table and able to get them from the table ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> - Added `run_csv_rtp_table` to schema_6.py file - Added runTimeParameterFiles field to the run creation request model - Passed rtp files input onto the Run Orchestrator’s load process - Added `insert_csv_rtp()` and `get_all_csv_rtp()` function - Updated `get_reference_data_files()` to add file referenced in runs - Updated tests --------- Co-authored-by: shiyaochen <[email protected]> Co-authored-by: Sanniti <[email protected]>
… and runs to set in-protocol values (#15855) # Overview Closes AUTH-419. This PR hooks up the setting of runtime parameter files in the POST `/runs`, `/protocols` and `/protocols/{protocolId}/analyses` to the actual `CSVParameter` object used in the protocol context. This file is sent via a dictionary of parameter name and file-id, so we resolve the file-id into a `Path` by using the `data_files_directory` and `data_files_store`. This is then passed to the `ParameterContext` and used to open up a temporary file that contains the contents of the actual file stored on the robot. ## Test Plan and Hands on Testing Tested end to end via the following protocol and two CSV files ``` metadata = { 'protocolName': 'CSV End to End Test', } requirements = { "robotType": "Flex", "apiLevel": "2.18" } def add_parameters(parameters): parameters.add_str( display_name="Pipette Name", variable_name="pipette", choices=[ {"display_name": "Single channel 50µL", "value": "flex_1channel_50"}, {"display_name": "Single channel 1000µL", "value": "flex_1channel_1000"}, {"display_name": "Eight Channel 50µL", "value": "flex_8channel_50"}, {"display_name": "Eight Channel 1000µL", "value": "flex_8channel_1000"}, ], default="flex_1channel_50", description="What pipette to use during the protocol.", ) parameters.add_csv_file( display_name="CSV Data", variable_name="csv_data", description="CSV file containing labware and volume information." ) def run(context): PIPETTE_NAME = context.params.pipette trash_bin = context.load_trash_bin('A3') tip_rack = context.load_labware('opentrons_flex_96_tiprack_50ul', 'D2') pipette = context.load_instrument(PIPETTE_NAME, mount="left", tip_racks=[tip_rack]) csv_file_data = context.params.csv_data.parse_as_csv() labware_name = csv_file_data[1][0].strip() location = csv_file_data[1][1].strip() volume = float(csv_file_data[1][2]) labware = context.load_labware(labware_name, location) pipette.pick_up_tip() pipette.aspirate(volume, labware.wells()[0].top()) pipette.dispense(volume, labware.wells()[1].top()) pipette.drop_tip() ``` ``` Labware Name, Location, Volume opentrons_96_wellplate_200ul_pcr_full_skirt, C1, 20 ``` ``` Labware Name, Location, Volume nest_96_wellplate_100ul_pcr_full_skirt, C2, 30 ``` ## Changelog - Resolve `runTimeParameterFiles` into a dictionary of `Paths` - pass the `run_time_param_paths` all the way to the `ParameterContext` where they can be opened as temporary file handlers - close the file handlers upon protocol end - Allow importing of `CSVParameter` from the `protocol_api` namespace. ## Review requests ## Risk assessment Medium. --------- Co-authored-by: Sanniti <[email protected]>
* fix(app)switch navlink to useNavigate for tabas in run setup
# Overview According to new modal designs for labware/adapter/module stacks on desktop and ODD, we need to render an isometric view of each element of the stack, maintaining the topography of each stacked element. The isometric views are constructed by transforming and aligning the labware SVG (top face) along with two new rects (front and left side). All three are scaled, skewed, and rotated at 30˚ angles or its derivatives ([reference](http://jeroenhoek.nl/articles/svg-and-isometric-projection.html)). The "bottom" labware definition is an optional prop, so we have an affordance for rendering an isometric view of a single labware from the same component. The user can choose to highlight both or none of the labware in the stack, resulting in a fill of blue30. In addition, adapters are handled in the following way: - If the adapter is used as the top definition and there is no bottom definition, we render the non-transformed `LabwareAdapter` svg - if the adapter is used as the bottom definition, we render the isometric transform of the well-less adapter face. _**NOTE**_ In this PR, the adapter's height is maintained, but we may also consider setting the height for a bottom adapter as a constant, rendering a standard-height rectangular prism with well-less face. Closes [PLAT-374](https://opentrons.atlassian.net/browse/PLAT-374), [PLAT-377](https://opentrons.atlassian.net/browse/PLAT-377), [PLAT-394](https://opentrons.atlassian.net/browse/PLAT-394), [PLAT-375](https://opentrons.atlassian.net/browse/PLAT-375)
…5883) # Overview closes https://opentrons.atlassian.net/browse/EXEC-504. add an end point in runs router to fetch commands error list. ## Test Plan and Hands on Testing - Post a protocol that will cause a recovery workflow. - Start the run and let the command fail. - Resume from recovery. - Let the run end. - GET `/runs/{runId}/commandErrors` and make sure you are getting the full command error list. ## Changelog - added an end point to commands router `/runs/{runId}/commandErrors`. - added logic in `CommandsState` to `get_error_slice`. ## Review requests naming makes sense? changes make sense? location for the new route makes sense? (under commands router) ## Risk assessment low. adding new logic
Closes RQA-2842 Migrates the logic for building RunProgressMeter's step copy to its own utility, cleaning up the order of operations slightly. Refactors the final step text from nothing to "N/A" when the run is canceled before starting.
…ise `MustHomeError` (#15900)
Co-authored-by: Ed Cormany <[email protected]>
In the run page on both app and ODD, you get an indication of completion when you get all your instruments and modules and deck stuff present and calibrated. But those are just two of the steps presented equally in the run setup page, and the rest of the steps don't get anything similar. It leads people to wonder whether they've set things up properly. This PR adds similar styling and completion semantics for the other tasks in the run setup screen to fix this issue. Specifically, LPC gets a "confirm offsets" button (which will confirm offsets even if you haven't run LPC - makes it more apparent that that's a separate option) and labware and liquids get generic confirm buttons. There's also a couple other visual fixes: - On desktop, the "back to top" button in run setup is now where figma thinks it is, outside the run-setup content area. This allows some refactoring of component props - On desktop, there was an issue with the react-router upgrade (I think - it's also in the latest IR alpha) that means that if you had an ongoing run, you couldn't view anything but run details without getting instantly navigated back to run details This implements this figma: https://www.figma.com/design/Rwdt9R0aERFC55oTLDTlqY/8.0-September-Release-File?node-id=39-35830&t=l6vwJjQsfyVeovfC-4 ## To come out of draft - [x] implement for ODD - [x] rebase onto release - [x] "are you sure" modal on desktop - [x] "are you sure" modal on ODD ## Review requests - This is some pretty complex UI - do you agree with how I've done this? - Some of this is pretty ugly, in large part because this is old code that I'm cleaning up. There's some duplicated logic in the run details and some pretty ugly typing. What I'd like to do is merge this since it implements some features nicely and then follow up with a refactor to get the size of some of these files down and enforce nicer separation between everything. ## Testing - [x] Desktop green checks on flex - [x] Desktop green checks on OT-2 (yes, this has to be different because the steps can be different here) Closes RSQ-7
…tocolContext.define_liquid()` (#15906)
…5913) <!-- 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 Should have realized it was wrong when I had to change the test <!-- 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. --> Co-authored-by: caila-marashaj <[email protected]>
Closes RQA-2904 The logic for rendering InterventionModal on the ODD/Desktop is a little bit different when looking at the exact conditions, and this (likely) causes the InterventionModal to render on the ODD sometimes but not on the desktop app, and vice versa. This is a good opportunity to refactor all of this logic into its own hook and use that hook where we render InterventionModal. After thinking through the render logic, there's room to simplify it a bit, too. We don't actually need stateful storage of an intervention command key. Also, I decided to separate showModal from modalProps (which lets us pass all the non-null props simply), even though we could technically just do a truthy check for modalProps for rendering InterventionModal, since this is maybe a bit more intuitive. Lastly, a few missing tests are added. To help with bug testing intervention modals, I added a couple console.warns.
To give clarity to the contents of labware/adapter/module stacks, here, I add a modal when clicking a stack on Labware setup deck map (for both Desktop and ODD). Each element of the stack will be highlighted described in a list item containing the element's name, optional nickname, and isometric SVG or PNG representation depending on its type. Closes [PLAT-376](https://opentrons.atlassian.net/browse/PLAT-376), [PLAT-378](https://opentrons.atlassian.net/browse/PLAT-378)
y3rsh
force-pushed
the
partial_tip_smoke_test
branch
from
fa52808
to
320a576
Compare
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.
End to End test cases for partial tip refactor