-
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
fix(api): Fix floating point errors and backwards incompatibility in volume validation #14253
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## edge #14253 +/- ##
==========================================
+ Coverage 68.53% 68.58% +0.04%
==========================================
Files 2421 2513 +92
Lines 67108 71392 +4284
Branches 8823 9089 +266
==========================================
+ Hits 45993 48961 +2968
- Misses 19040 20340 +1300
- Partials 2075 2091 +16
Flags with carried forward coverage won't be shown. Click here to find out more.
|
78c56ea
to
fe19e37
Compare
fe19e37
to
fc9e39b
Compare
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.
Yeah, this looks good to me! I agree with the PE dispense change, nice fix.
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.
LGTM, keeps everything consistent now.
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.
If everyone else is cool with this to-do hanging out in the release notes file for now, it's fine with me too. Otherwise, we can offload it to a comment on RTC-384 until the time is right.
I'm not sure what the deal was with the timing out G-Code-Confirm test, but it works when I trigger it manually. I'm unable to easily test on an actual robot at the moment because of unrelated boot problems, but I'm satisfied with our automated test coverage for now. |
# Overview Add protocols pulled from v7.2.0 pull requests for Analysis Snapshot testing. All work filed under [RQA-2434](https://opentrons.atlassian.net/browse/RQA-2434) # Test Plan - [x] Add partial tip pickup protocols from Sanitti - [x] Add ABR protocol from [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) - [x] Run new protocols locally and verify results - [x] Run in workflow dispatch action and verify success [[link]](https://github.com/Opentrons/opentrons/actions/runs/8160792870/job/22308167177) # Changelog Here are the protocols added and where I found them: - [RQA-2098](https://opentrons.atlassian.net/browse/RQA-2098) - Flex_P1000_96_Gripper_TC_TM_HS_AnalysisError_GripperCollisionWithTips.json - #14491 - Flex_None_None_TC_2_14_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_15_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_16_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_17_verifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_14_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_15_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_16_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_17_VerifyThermocyclerLoadedSlots.py - #14475 - Flex_None_None_TC_2_16_AnalysisError_TrashBinAndThermocyclerConflict.py - OT2_None_None_2_16_verifyDoesNotDeadlock.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin1.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin2.py - #14547 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLid.py - #14522 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLidClips.py - Dispense functionality validation - OT2_P300M_P20S_TC_HS_TM_2_15_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_16_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_17_dispense_changes.py - #14253 - OT2_P300S_None_2_16_verifyNoFloatingPointErrorInPipetting.py # Review requests There are a few pull requests that I had questions about. I will @ the people that worked on them to answer the questions - #14437 - @sfoster1, Can I use the protocol found in [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) to get this to happen? Is there another way? - #14509 - @SyntaxColoring, can analysis capture this change or is this only relavant during actual protocol runtime? - #14510 - @TamarZanzouri or @SyntaxColoring, can I raise a generic python exception inside the protocol to trigger this functionality? - #14512 - @Laura-Danielle or @SyntaxColoring, Iant to validate my logic. This not a good canidate for snapshot testing because you have to run LPC and Calibration which is not taken into account during analysis. Can you confirm? # Risk assessment None [RQA-2434]: https://opentrons.atlassian.net/browse/RQA-2434?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RQA-2098]: https://opentrons.atlassian.net/browse/RQA-2098?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RABR-23]: https://opentrons.atlassian.net/browse/RABR-23?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Add protocols pulled from v7.2.0 pull requests for Analysis Snapshot testing. All work filed under [RQA-2434](https://opentrons.atlassian.net/browse/RQA-2434) - [x] Add partial tip pickup protocols from Sanitti - [x] Add ABR protocol from [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) - [x] Run new protocols locally and verify results - [x] Run in workflow dispatch action and verify success [[link]](https://github.com/Opentrons/opentrons/actions/runs/8160792870/job/22308167177) Here are the protocols added and where I found them: - [RQA-2098](https://opentrons.atlassian.net/browse/RQA-2098) - Flex_P1000_96_Gripper_TC_TM_HS_AnalysisError_GripperCollisionWithTips.json - #14491 - Flex_None_None_TC_2_14_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_15_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_16_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_17_verifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_14_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_15_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_16_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_17_VerifyThermocyclerLoadedSlots.py - #14475 - Flex_None_None_TC_2_16_AnalysisError_TrashBinAndThermocyclerConflict.py - OT2_None_None_2_16_verifyDoesNotDeadlock.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin1.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin2.py - #14547 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLid.py - #14522 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLidClips.py - Dispense functionality validation - OT2_P300M_P20S_TC_HS_TM_2_15_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_16_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_17_dispense_changes.py - #14253 - OT2_P300S_None_2_16_verifyNoFloatingPointErrorInPipetting.py There are a few pull requests that I had questions about. I will @ the people that worked on them to answer the questions - #14437 - @sfoster1, Can I use the protocol found in [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) to get this to happen? Is there another way? - #14509 - @SyntaxColoring, can analysis capture this change or is this only relavant during actual protocol runtime? - #14510 - @TamarZanzouri or @SyntaxColoring, can I raise a generic python exception inside the protocol to trigger this functionality? - #14512 - @Laura-Danielle or @SyntaxColoring, Iant to validate my logic. This not a good canidate for snapshot testing because you have to run LPC and Calibration which is not taken into account during analysis. Can you confirm? None [RQA-2434]: https://opentrons.atlassian.net/browse/RQA-2434?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RQA-2098]: https://opentrons.atlassian.net/browse/RQA-2098?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RABR-23]: https://opentrons.atlassian.net/browse/RABR-23?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Add protocols pulled from v7.2.0 pull requests for Analysis Snapshot testing. All work filed under [RQA-2434](https://opentrons.atlassian.net/browse/RQA-2434) - [x] Add partial tip pickup protocols from Sanitti - [x] Add ABR protocol from [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) - [x] Run new protocols locally and verify results - [x] Run in workflow dispatch action and verify success [[link]](https://github.com/Opentrons/opentrons/actions/runs/8160792870/job/22308167177) Here are the protocols added and where I found them: - [RQA-2098](https://opentrons.atlassian.net/browse/RQA-2098) - Flex_P1000_96_Gripper_TC_TM_HS_AnalysisError_GripperCollisionWithTips.json - #14491 - Flex_None_None_TC_2_14_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_15_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_16_verifyThermocyclerLoadedSlots.py - Flex_None_None_TC_2_17_verifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_14_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_15_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_16_VerifyThermocyclerLoadedSlots.py - OT2_None_None_TC_2_17_VerifyThermocyclerLoadedSlots.py - #14475 - Flex_None_None_TC_2_16_AnalysisError_TrashBinAndThermocyclerConflict.py - OT2_None_None_2_16_verifyDoesNotDeadlock.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin1.py - OT2_None_None_HS_2_16_AnalysisError_HeaterShakerConflictWithTrashBin2.py - #14547 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLid.py - #14522 - Flex_P1000_96_None_TC_2_16_AnalysisError_pipetteCollisionWithThermocyclerLidClips.py - Dispense functionality validation - OT2_P300M_P20S_TC_HS_TM_2_15_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_16_dispense_changes.py - OT2_P300M_P20S_TC_HS_TM_2_17_dispense_changes.py - #14253 - OT2_P300S_None_2_16_verifyNoFloatingPointErrorInPipetting.py There are a few pull requests that I had questions about. I will @ the people that worked on them to answer the questions - #14437 - @sfoster1, Can I use the protocol found in [RABR-23](https://opentrons.atlassian.net/browse/RABR-23) to get this to happen? Is there another way? - #14509 - @SyntaxColoring, can analysis capture this change or is this only relavant during actual protocol runtime? - #14510 - @TamarZanzouri or @SyntaxColoring, can I raise a generic python exception inside the protocol to trigger this functionality? - #14512 - @Laura-Danielle or @SyntaxColoring, Iant to validate my logic. This not a good canidate for snapshot testing because you have to run LPC and Calibration which is not taken into account during analysis. Can you confirm? None [RQA-2434]: https://opentrons.atlassian.net/browse/RQA-2434?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RQA-2098]: https://opentrons.atlassian.net/browse/RQA-2098?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [RABR-23]: https://opentrons.atlassian.net/browse/RABR-23?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Overview
This fixes two bugs: RQA-2001 and RESC-182.
RQA-2001 is that if you had an incorrect protocol like this:
...then it has started to raise an exception instead of silently clamping
100
to50
. This is a good thing to do, but it's a backwards-incompatible change, and it should have been behind anapiLevel
bump. This PR makes the change opt-in, behind"apiLevel": "2.17"
.RESC-182 is related. If you had a correct protocol like this:
...then it has started to raise "invalid volume" errors stemming from floating point rounding errors. This is more straightforwardly a bug; it should just not do that.
Test Plan
I've tested this with the protocols from the tickets.
Background
The long-standing historical behavior (since #2481 at least) seems to be that we clamp dispenses but do strict bounds-checking on aspirates. I'm not sure why they differed from each other. I'm also not sure how the strict bounds-checking on aspirates never caused any problems with floating point rounding.
In RSS-330 / PR #13546, we added strict bounds-checking to the Protocol Engine
dispense
command. We mistakenly thought we were fixing an omission and bringing simulation in line with execution, but we were actually making a breaking change to the interface. And, separately, we forgot about floating point error.Changelog
/runs
API). We could perhaps add a"clamp": true
param todispense
to change that, but I suspect it's not worthwhile."apiLevel"
.Review requests
dispense
command?Risk assessment
Medium.