feat(app): Implement two cols RadioButton controller #15634
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
… moves (#15564) Refactors liquid_probe- z distances for each pass are now calculated using appropriate plunger distance for the given pipette model/tip combination
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> # Test Plan <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> # Changelog <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. -->
I don't know where in my brain this idea came from but both the ODD and the desktop want to show this screen. ## testing - [x] enter ER on the desktop app and it shows a splash screen and a wizard when you click the "enter error recovery button"
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> Delete the current, incorrect, checks in execution of liquid_probe and replace them with individual, specific checks for tip presence, working volume, and pipette position fix EXEC-591 # Test Plan <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> Added 3 unit tests to test_liquid_probe.py to make sure the proper errors are being raised. 1 for tip attachment error, 1 for tip empty error, and 1 for position error. # Changelog <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> Error checks in execute in liquid_probe.py New unit tests in test_liquid_probe.py New exception type called "TipNotEmptyError" in `protocol_engine/errors/exceptions.py`. It is marked as a "GENERAL_ERROR". New get_is_empty function in `protocol_engine/execution/pipetting.py`. # Review requests <!-- Describe any requests for your reviewers here. --> I'm not sure if adding the get_is_empty function is the proper thing to do but I didn't know how to check the working volume another way without breaking some layer of abstraction. # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. --> Low.
* feat(app): add aria-disabled for displaying snack bar
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> This PR changes Protocol API APIVersionError to inherit from enumerated error IncorrectAPIVersion and Protocol API UnsupportedAPIError to inherit from enumerated error APIRemoved. # Test Plan <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> # Changelog <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. -->
This PR is an automated snapshot update request. Please review the changes and merge if they are acceptable or find your bug and fix it. Co-authored-by: y3rsh <[email protected]>
#15607) ## always() left out These steps won't run unless `always()` is included in the step conditional if the workflow had a previous step fail.
) # Overview Adds the ability to configure the behavior of the system resource tracker monitoring script through environment variables. Closes [EXEC-597](https://opentrons.atlassian.net/browse/EXEC-597) # Test Plan - [x] Pull this branch - [x] Go to `performance-metrics` project - [x] Run `make teardown && make setup` to ensure python env is up to date - [x] Ensure performance metrics ff is enabled by running `make set-performance-metrics-ff host=<robot_ip>` - [x] Push changes to Flex or Dev Kit by running ` make setup-remote-flex host=10.10.10.151 ssh_key=~/.ssh/flex_ssh_key` - [ ] ssh to the robot - [x] Wipe any existing performance metrics data `rm -fr /data/performance_metrics_data` - [x] Go to `/opt/opentrons-robot-server` - [x] Run `python3 -m performance_metrics.system_resource_tracker` - [x] Verify you get a log message that looks like the following ``` 2024-07-09 14:31:40,347 - __main__ - main() - INFO - Running with the following configuration: enabled=False process_filters=('/opt/opentrons*', 'python3*') refresh_interval=10.0 storage_dir=/data/performance_metrics_data logging_level=INFO ``` - [x] Kill the process with CTRL + C - [ ] Ensure that system resources are captured by looking at system_resource_tracker files in /data/performance_metrics - [ ] Run `OT_SYSTEM_RESOURCE_TRACKER_REFRESH_INTERVAL=15.0 OT_SYSTEM_RESOURCE_TRACKER_LOGGING_LEVEL=DEBUG python3 -m performance_metrics.system_resource_tracker` - [ ] Verify the initial log message about the configuration has changed to something like: ``` 2024-07-09 14:31:40,347 - __main__ - main() - INFO - Running with the following configuration: enabled=False process_filters=('/opt/opentrons*', 'python3*') refresh_interval=15.0 storage_dir=/data/performance_metrics_data logging_level=DEBUG ``` - [ ] Verify you are now getting a ton more log messages but less frequently - [ ] Kill the process with CTRL + C - [ ] Ensure that more system resources captures have been added by looking at system_resource_tracker files in /data/performance_metrics # Changelog - Add make targets to assist in setting up performance-metrics on robot - Add `performance_metrics.system_resource_tracker._config` containing SystemResourceTrackerConfiguration class which has all values that can be configured for the SystemResourceTracker - Update SystemResourceTracker to use SystemResourceTrackerConfiguration - Add pulling config from environment variables and using it in __main__.py - Add logging for debugging purposes - Add tests # Review requests I configured all the performance metrics loggers to use the same name so I can update the log level of all of them inside of main. Is this the correct way to ensure all of them get updated? Or is there a better way # Risk assessment Low [EXEC-597]: https://opentrons.atlassian.net/browse/EXEC-597?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
…vice (#15604) # Overview Add the definition of systemd service files and scripts to ensure that they work Closes [EXEC-596](https://opentrons.atlassian.net/browse/EXEC-596) # Changelog - Defined 2 different service files a prod and dev - Added systemd-python so systemd can be notified when service is ready - Added some helper scripts for setting up and cleaning up on remote server # Review requests Take a look at my service files. This is my first time creating them. I read docs on how to do it and they work but would like some special attention paid to them. # Risk assessment Still low, nothing is installed or running by default. You have to run scripts to get them on the robot # Test Plan **Putting this at the end since it's long** - [ ] pull this branch - [ ] Go into `performance-metrics` directory - [ ] run `make teardown && make setup` as dependencies have changed - [ ] Run `make setup-performance-metrics-project-on-remote-flex host=<robot-ip> ssh_key=<key-path>` - [ ] ssh to robot - [ ] Run `cat /data/feature_flags.json` and ensure `enabledPerformanceMetrics` is set to `true` - [ ] exit ssh - [ ] Run `make cleanup-remote-server host=<robot-ip> ssh_key=<key-path>` - [ ] As long as you haven't already configured the service the output should look like this: ``` Cleaning up performance metrics on host 10.10.10.151... Configuring remote file system to read/write Stopping system-resource-tracker Failed to stop system-resource-tracker.service: Unit system-resource-tracker.service not loaded. Disabling system-resource-tracker Failed to disable unit: Unit file system-resource-tracker.service does not exist. Reloading daemon Checking system-resource-tracker status inactive Removing service file, data folders, and performance_metrics package Remounting filesystem as read-only Unsetting performance metrics feature flag ``` - [ ] Run `make setup-performance-metrics-project-on-remote-flex host=<robot-ip> ssh_key=<key-path>` as the clean command removed and unset everything - [ ] Run `make setup-prod-system-resource-tracker-systemd-service host=<robot-ip> ssh_key=<key-path>` - [ ] You should get output that looks like this ``` Configuring remote file system to read/write Pushing system-resource-tracker.service to remote system-resource-tracker.service 100% 445 63.8KB/s 00:00 Enabling service Restarting service Checking service status active Configuring remote file system to read-only ``` - [ ] ssh into robot - [ ] Run `cat /data/feature_flags.json` and ensure `enabledPerformanceMetrics` is set to `true` - [ ] Run `cat /etc/systemd/system/system-resource-tracker.service` and confirm that the output matches the `system-resource-tracker.service` file in the repo - [ ] Run `systemctl status system-resource-tracker | cat` your output should look something like this: ``` ● system-resource-tracker.service - Opentrons System Resource Tracker Loaded: loaded (/etc/systemd/system/system-resource-tracker.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2024-07-09 17:40:20 UTC; 6min ago Main PID: 43800 (python3) Tasks: 1 (limit: 1761) Memory: 9.6M CGroup: /system.slice/system-resource-tracker.service └─ 43800 python3 -m performance_metrics.system_resource_tracker Jul 09 17:40:20 9608de python3[43800]: process_filters=('/opt/opentrons*', 'python3*') Jul 09 17:40:20 9608de python3[43800]: refresh_interval=15.0 Jul 09 17:40:20 9608de python3[43800]: storage_dir=/data/performance_metrics_data Jul 09 17:40:20 9608de python3[43800]: logging_level=INFO Jul 09 17:40:20 9608de python3[43800]: 2024-07-09 17:40:20,176 - _metrics_store - setup() - INFO - Setting up metrics store for system_resource_data at /data/performance_metrics_data Jul 09 17:40:20 9608de /opt/opentrons-robot-server/performance_metrics/system_resource_tracker/__main__.py[43800]: 2024-07-09 17:40:20,174 - __main__ - main() - INFO - Running with the following configuration: enabled=True process_filters=('/opt/opentrons*', 'python3*') refresh_interval=15.0 storage_dir=/data/performance_metrics_data logging_level=INFO Jul 09 17:40:20 9608de /opt/opentrons-robot-server/performance_metrics/system_resource_tracker/__main__.py[43800]: 2024-07-09 17:40:20,176 - _metrics_store - setup() - INFO - Setting up metrics store for system_resource_data at /data/performance_metrics_data Jul 09 17:40:20 9608de python3[43800]: 2024-07-09 17:40:20,296 - __main__ - main() - INFO - Starting system resource tracker... Jul 09 17:40:20 9608de /opt/opentrons-robot-server/performance_metrics/system_resource_tracker/__main__.py[43800]: 2024-07-09 17:40:20,296 - __main__ - main() - INFO - Starting system resource tracker... Jul 09 17:40:20 9608de systemd[1]: Started Opentrons System Resource Tracker. ``` - [ ] Run `ls -l /data/performance_metrics_data/` and take note of the size of system_resource_data - [ ] Wait like 30 seconds and run ls command again. You should see that `system_resource_data` gets larger - [ ] exit ssh - [ ] Run `make cleanup-remote-server host=<robot-ip> ssh_key=<key-path>` - [ ] You should get this output ``` Cleaning up performance metrics on host 10.10.10.151... Configuring remote file system to read/write Stopping system-resource-tracker Disabling system-resource-tracker Removed /etc/systemd/system/multi-user.target.wants/system-resource-tracker.service. Reloading daemon Checking system-resource-tracker status inactive Removing service file, data folders, and performance_metrics package Remounting filesystem as read-only Unsetting performance metrics feature flag ``` [EXEC-596]: https://opentrons.atlassian.net/browse/EXEC-596?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Added section to read a json file in the measurement folder containing all robot IP's and expected volumes moved based on robot name.--> # Test Plan <!-- Tested steps 1, 2, and 3 with measurements. I do not believe more testing is needed. --> # Changelog <!-- - added json file reader for IP's and volumes - added recovery if "Y" or "N" were not input after a measurement --> # Review requests <!-- N/A --> # Risk assessment <!-- This script is not relied on in any other script. -->
* refactor(api-client): remove stub for csv file
… setting and return error if limit is reached (#15590) Co-authored-by: Brent Hagen <[email protected]>
…id/filePath and fileName re AUTH-521
koji
reviewed
Jul 15, 2024
koji
reviewed
Jul 15, 2024
koji
reviewed
Jul 15, 2024
koji
reviewed
Jul 15, 2024
| ) : null} | ||
| </> | ||
| )) | ||
| csvFilesOnUSB.map(csv => { |
There was a problem hiding this comment.
sorry, this is my fault.
Suggested change
| csvFilesOnUSB.map(csv => { | |
| csvFilesOnUSB.map(csvFilePath => { |
koji
approved these changes
Jul 15, 2024
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
AUTH-521: Implementing functionality to control radio buttons in two columns for selecting a CSV file on robot or on USB. When users tabbed back button after they selected a file, updating parameters with file id and file name for a file selected on robot or with file path and file name for a file selected on USB.
AUTH-558: Replacing the confirm selection button with an inline notification and updating back button control.
Test Plan
Changelog
Review requests
Risk assessment