-
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,shared-data): Correct addressable area positions #14100
fix(api,shared-data): Correct addressable area positions #14100
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## chore_release-7.1.0 #14100 +/- ##
=======================================================
- Coverage 70.46% 70.46% -0.01%
=======================================================
Files 2512 2512
Lines 71185 71183 -2
Branches 8957 8957
=======================================================
- Hits 50158 50156 -2
Misses 18836 18836
Partials 2191 2191
Flags with carried forward coverage won't be shown. Click here to find out more.
|
…tions Resolve conflict in api/src/opentrons/protocol_engine/types.py.
There are additional JavaScript things, which are being addressed in a different PR.
…tions Resolve a conflict in api/tests/opentrons/protocol_engine/state/test_addressable_area_store.py.
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.
thank you! This makes sense to me. I tested uploading a JSON file where i manually changed the 1and8ChannelWasteChute
addressable area name to 1ChannelWasteChute
and it passed analysis 🥳
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.
Reviewed in person. I'll go through the calculations thoroughly for my understanding later but the logic makes sense and looks good to merge!
I don't understand how to interpret the dimensions in the old fixed trash labware, and I'm scared of messing with the drop-tip point, so I guess let's make these 0-sized points in the same place as the old dropTipsOffsets. This means the fixedTrash and shortFixedTrash addressable areas will no longer have the same origin as the v3 defs' slot 12. That's fine and actually makes sense. Those addressable areas are supposed to be equivalent to a v3 well position, not a v3 deck slot position.
…tions Resolve a conflict in api/src/opentrons/protocol_api/core/engine/instrument.py.
Overview
This closes RSS-408.
Test Plan
I've used these protocols to test: Addressable area tests.zip
I only have an old waste chute to test with, so I couldn't directly test the y-position for 1- and 8-channel tip drops. (I cannot use the new waste chute cover.) So I held up the cover while the protocol was paused and eyeballed it.
Changelog
1and8ChannelWasteChute
addressable area into1ChannelWasteChute
and8ChannelWasteChute
.dropTipsOffset
from the addressable area definitions. This was unused.dropLabwareOffset
from the addressable area definitions. This was used by Protocol Engine.offsetFromCutoutFixture
s andboundingBox
es so the bounding box's top-center is at the expected interaction point.Review requests
None in particular.
Risk assessment
Medium. This affects motion planning, so we need to manually test a bunch of pipette positions and make sure there are no collisions.