-
Notifications
You must be signed in to change notification settings - Fork 179
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(ot3): add shared data support for ot3 pipettes #11704
feat(ot3): add shared data support for ot3 pipettes #11704
Conversation
We need a better way to encapsulate the new functionality that ot3 pipettes has, as well as the types of pipettes available.
Codecov Report
@@ Coverage Diff @@
## RLIQ-131-support-96-channel #11704 +/- ##
==============================================================
Coverage ? 74.40%
==============================================================
Files ? 2089
Lines ? 58016
Branches ? 6158
==============================================================
Hits ? 43164
Misses ? 13403
Partials ? 1449
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 so much nicer!
That said,
- let's get the new schema data in the README
- can you say a little more in the README and/or pr description about what the 3d files are for?
- can you say a little more in the README and/or pr description about what the
T200
/T50
things are for and how they'll be used?
@@ -0,0 +1,5 @@ | |||
{ | |||
"$otSharedSchema": "#/pipette/schemas/2/pipetteGeometrySchema.json", | |||
"pathTo3D": "pipette/definitions/2/eight_channel/p1000/placeholder.gltf", |
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.
?
}) | ||
|
||
liquidPaths.forEach(liquidPath => { | ||
const filename = path.parse(liquidPath).base |
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.
As CI says, you don't use filename
. Maybe just remove this line?
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.
Went through and checked config values based off values we're currently using in testing
shared-data/pipette/definitions/2/liquid/single_channel/p50/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/single_channel/p50/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/single_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/single_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/single_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/ninety_six_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/ninety_six_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/liquid/ninety_six_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/general/ninety_six_channel/p1000/1.json
Outdated
Show resolved
Hide resolved
shared-data/pipette/definitions/2/general/ninety_six_channel/p1000/1.json
Show resolved
Hide resolved
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.
I've got a couple tiny comments with an eye towards RCORE-382 and some yet-to-be-written PAPI tickets for 96-channel support, but otherwise this looks really solid and a vast improvement over the old configs
"patternProperties": { | ||
"description": "Tip specific liquid handling properties for a given pipette. Using the active tip on a pipette, we will look up the pipetting configurations associated with that tip+pipette combo.", | ||
"type": "object", | ||
"$comment": "Example key: 'T50'", | ||
"^T[0-9]{2,4}": { |
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.
A couple notes:
- Pattern properties are not easy to to map into Pedantic and other runtime models
- I would softly prefer lowercase identifiers to upper or mixed-case
Could this be a list instead with a string field for the t50
(or whatever) portion?
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.
@mcous could I wrap the tip types in a top level key instead? I.e.:
supportedTips: {
t50 {...},
t200 {...},
}
etc? That way I can load the pydantic models based on the guaranteed keys inside each nested "tip" object and then I can use the top level pattern property keys to create a look-up table.
"availableSensors": { | ||
"type": "object", | ||
"description": "object with keyed by sensor and number available", | ||
"required": ["pressure", "capacitive", "environment"], | ||
"properties": { | ||
"pressure": { "enum": [1, 2] }, | ||
"capacitive": { "enum": [1, 2] }, | ||
"environment": { "enum": [1] } | ||
} | ||
}, |
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 specific capabilities list is a little hard to understand coming in blind. Can we make one of both of these changes?
- Change to a list so we can define new sensors without changing the schema?
- Do something like
pressure: { count: number }
rather thanpressure: number
to make it more obvious what's going on when reading the data?
As an aside, how is the sensor count data used?
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.
It is not currently used, but it will be used in the expanded pipette object class for ot3 pipettes to know how many sensor objects to build (will mainly be used for liquid sensing purposes)
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.
@mcous what do you think about this:
Available sensors is still an object that contains:
- A list of available sensors (can be anything)
- A pattern property which is keyed by sensor type and the object it contains is
{count: number}
Then, an available sensors object might look like:
availableSensors: {
"sensors": ["pressure", "capacitive", "environment"],
"pressure": {count: 2},
"capacitive": {count: 1},
"environment": {count: 1}
}
talked f2f, seth is OK with merging into feature branch
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.
Looks awesome!
Overview
We need a better way to encapsulate the new functionality that ot3 pipettes has, as well as the
types of pipettes available. I will be splitting up this work into a series of bits of work ticketed here.
Changelog
Review requests
Risk assessment
Low. Not being used yet.