-
Notifications
You must be signed in to change notification settings - Fork 178
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
feat(hardware): handle motor driver errors #13867
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## edge #13867 +/- ##
=======================================
Coverage 67.17% 67.18%
=======================================
Files 2495 2495
Lines 71608 71651 +43
Branches 9075 9075
=======================================
+ Hits 48104 48140 +36
- Misses 21360 21367 +7
Partials 2144 2144
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
This is looking really good! Let's just fix up those last lint and test problems. Good call on the error code value and location!
…com/Opentrons/opentrons into RET-1025_handle_motor_driver_errors
This PR enables the reporting of Flex motor driver errors, adding the MotorDriverError exception. Specific motor driver errors are over-temperature, short circuit, and open circuit. An ErrorMessage is reported from the Flex firmware in two cases: 1. As a response to a move request when a motor driver is in error state. In this case, the error is logged. 2. If a motor driver enters error state during a move. In this case, a subsequent ReadMotorDriverErrorStatusResponse message is reported from the Flex firmware, which details the specific error. This PR logs these messages and also raises these messages as MotorDriverError exceptions. <!-- 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 - [ ] Test both use cases on robot. In second use case, ensure ReadMotorDriverErrorStatusResponse message is associated with requesting MoveID. - [x] Write software tests for both use cases. In second use case, ensure each specific error is parsed. <!-- 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 Low. Adds MotorDriverError to existing list of exceptions. Introduces handling and parsing of ReadMotorDriverErrorStatusResponse message, using existing well-tested frameworks and concepts. <!-- 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 enables the reporting of Flex motor driver errors, adding the MotorDriverError exception. Specific motor driver errors are over-temperature, short circuit, and open circuit. An ErrorMessage is reported from the Flex firmware in two cases:
Overview
Test Plan
Changelog
Review requests
Risk assessment
Low. Adds MotorDriverError to existing list of exceptions. Introduces handling and parsing of ReadMotorDriverErrorStatusResponse message, using existing well-tested frameworks and concepts.