fix(app): Verify attached/protocol pipettes #3458
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
Kadee80
added
bug
app
Codecov Report
@@ Coverage Diff @@
## edge #3458 +/- ##
==========================================
- Coverage 52.23% 52.14% -0.09%
==========================================
Files 794 794
Lines 23155 23219 +64
==========================================
+ Hits 12095 12108 +13
- Misses 11060 11111 +51
Continue to review full report at Codecov.
|
sfoster1
added a commit
that referenced
this pull request
May 14, 2019
When we introduced our pipetteModelSpecs/pipetteNameSpecs split for our pipette data, we settled on pipette 'name' being the _kind_ of pipette - 'p300_single', 'p10_multi', etc pipette 'model' being the specific model version of pipette - 'p300_single_v1.5', 'p+20_single_v2.0', etc However, we didn't fully realize this throughout our stack. The name attribute of both the robot singleton pipette objects and the hardware control pipette objects (and everything that depended on them) still used 'name' to mean 'model'. This causes confusion for devs and also bugs like #3458 This PR fixes that by - Making the 'name' attributes on both the old and new pipettes return the name - Making new 'model' attributes on old and new pipettes that return the model - Piping everything around internally There's also changes to the tests to adapt their internal mocks for the above. Though the above pr does fix the bug it mentions, this also provides another way for clients to avoid confusing the simulated _v1 pipettes and the real versioned pipettes: check that the pipette _names_ match between the /pipettes endpoint and the protocol rpc output.
sfoster1
added a commit
that referenced
this pull request
May 17, 2019
When we introduced our pipetteModelSpecs/pipetteNameSpecs split for our pipette data, we settled on pipette 'name' being the _kind_ of pipette - 'p300_single', 'p10_multi', etc pipette 'model' being the specific model version of pipette - 'p300_single_v1.5', 'p+20_single_v2.0', etc However, we didn't fully realize this throughout our stack. The name attribute of both the robot singleton pipette objects and the hardware control pipette objects (and everything that depended on them) still used 'name' to mean 'model'. This causes confusion for devs and also bugs like #3458 This PR fixes that by - Making the 'name' attributes on both the old and new pipettes return the name - Making new 'model' attributes on old and new pipettes that return the model - Piping everything around internally There's also changes to the tests to adapt their internal mocks for the above. Though the above pr does fix the bug it mentions, this also provides another way for clients to avoid confusing the simulated _v1 pipettes and the real versioned pipettes: check that the pipette _names_ match between the /pipettes endpoint and the protocol rpc output.
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
This PR served as both a Bug Report and a Bug Fix. Support had reported wrong/no pipette attached messages in File Info and Calibrate Pipettes pages even after the user had gone to instrument settings and attached the correct/missing pipettes. The app was comparing models vs name. This PR gets both actual and session pipette names from shared data to avoid pipette version mismatch.
changelog
review requests
Can be tested on sanniti-bot with
api/tests/opentrons/data/bradford_assay.py.detach one of the pipettes before loading protocol
upload protocol and observe missing/wrong pipette message in File Info and Calibrate Pipettes pages
attach the pipette
Missing pipette warning no longer exists in File Info Page
Missing pipette warning no longer exists in Calibrate Pipettes Page