Database storing common Labware (DWPs, etc.) specifications

This is helpful. I had not considered that labware definitions do not necessarily have go in via the manual definition process in the instrument software.

2 Likes

Funny you should ask, I’ve tackled this exact problem myself:

0 - Yes incredibly useful! I’ve made a sqlite DB containing labware specific data that gets queried, converted to JSON and passed into automated methods in Hamilton Venus. Lets labware selection happen dynamically instead of hardcoding loads into the method/ layout.
1 - Not that I’m aware of but if there is one (or will be one) it’d definitely be useful
3 - Would imagine relational since you don’t want dimensions like grip widths or aliquoting heights to accidently change from a simple save
4 - Would contain a fair few tables I imagine, like descriptive information, dimension data, lab robot specific data

Really big hurdle to get over would be manufacturers actually giving the right specifications if any. Equally liquid handlers seem to interpret different dimensions either inaccurately or in their own way. If there was a source whereby these issues were handled, it’d be incredible.

That being said, no idea how I’d implement it on an open source scale.

1 Like

That’s why “peer-validated” labware files become crucial. It may be instrument to instrument but it would be an incredible source of communal knowledge.

2 Likes

Great idea.
Every time i need to get labware specs i use the labware library provided by Opentrons. It is not perfect but it is a great starting point, if you click on the labware you can see the specs:

They also allow you to make your own labware using their labware format written in JASON. If you want to get a feel for how that looks then try to make your own labware:

The best thing about this is that Opentrons has done the hard work of making all these labware specs in a standardized format. I think you can find their JASON files on your own computer or the opentrons it self(I am looking into it now).

It could a short step from knowing the dimensions of the opentrons labware to adjusting to to your labware and then adding information about liquid height for each of the wells you are working with.

6 Likes

So, I see a bunch of folks all expressing interest in this problem: would people be interested in a Zoom call to discuss the various options proposed and see if there’s a joint plan agreeable to the group?

2 Likes

Wow the opentrons DB is pretty sweet!

2 Likes

@jakebeal I’d be happy to meet over zoom and talk about some options with the group

@jakebeal I’d be up for a zoom call to talk :slight_smile:

Since it looks like there’s a quorum of interest for putting a working group together, I’ve set up a poll for a time to meet next week with a set of times that work for me: Doodle

1 Like

I think this is a great idea. I think we should also couple this with a repository (wherever it is hosted) with libraries, documentation etc.

2 Likes

This came up at the Standards Special Interest Group (SIG) at SLAS 2022.

A key discussion point was how we can align incentives across labware manufacturers, liquid handler manufacturers, and users so that this becomes a win/win/win situation where all stakeholders are happy to contribute.

One challenge is that there’s no “uniform” abstract definition of labware. I see there’s one ontology proposed above in the thread (GitHub - Bioprotocols/container-ontology: Container ontology for use with PAML (Protocol Activity Markup Language)), but I don’t know how widely that is accepted. The efforts by OpenTrons (https://labware.opentrons.com/) are commendable and certainly make using a variety of labware on their platform much more streamlined; however, OpenTrons does not have a gripper and therefore the concept of lids and grip points on the labware are (understandably) missing from their database of labware definitions, which would be key requirements for labware definitions on many other robotic platforms.

However, there is already a widely accepted open standard for defining any arbitrary 3-dimensional object: CAD (STEP/STL).

Labware manufacturers already have CAD files for all their labware, and improvements in photogrammetry (aka “3D Scanning”) are rapidly reaching the point where even cell phones are capable of generating representations with sub-millimeter resolution. The latter enables end users to generate CAD files of labware while manufacturers are still starting to realize the benefit they can accrue by directly contributing their CAD files to the effort (if labware is already defined, the manufacturer benefits by users being more likely to purchase and deploy that labware in their workflows).

Adopting CAD as the standard avoids any need to have lengthy discussions about the best way to define an ontology describing labware. All that would be needed is a CAD file and a single defined point located anywhere within the volume of each well, which would serve as the nucleus of a space-filling algorithm that would automatically determine the dimensions of each “well” (or reservoir trough, or cryovial within a rack, etc.).

There are a variety of Python open source packages that can read in CAD files. These can be used to create “convertors” that take a CAD file as an input and output a labware definition in the format required for a specific liquid handler. Liquid handler manufacturers have the incentive to create and maintain the convertors so that users want to use their instruments, but this effort can be bootstrapped by open source contributions to create convertors by the community.

This could all be hosted on GitHub, where “peer review” is provided by someone approving the pull request to add a new CAD file or convertor to the repository. There could also be a simple static site generator within the repository that publishes a UI to GitHub pages that allows simple searching of the available labware—obviating the need to host a formal “database”.

It was a draft idea in discussion at SLAS2022, and most available volunteers were more focused on efforts within SiLA. However, if this format seems beneficial, and there are some people willing to help stand up the repository, it seems like it has a lot of potential.

2 Likes

The key is to have it peer reviewed. Customization is normal (modifying grip heights, etc…) but proper well definitions and sizes are still not ideal even for default (vendor provided) labware.

There could also be a simple static site generator within the repository that publishes a UI to GitHub pages that allows simple searching of the available labware—obviating the need to host a formal “database”.

Do you have an example of this in action?

1 Like

That all sounds great, but will manufacturer’s provide CAD drawings?

2 Likes

I think to get started, there can be a field within the schema that links to either the CAD file, or a .pdf with the technical drawing as a ground truth for the dimensions. Most big manufacturers (Thermo, Axygen, Bio-Rad, etc.) are very generous with their technical drawings, either linking them on their websites or emailing them to you through support requests.

The “peer-review” aspect will involve someone downloading the labware file, and signing off on things like “well-depth is correct”, “cLLD accurately measures the volume”, “grip teach points are adequate” etc. for an individual device. If anything needs to be adjusted ("I needed to move the grip point up 2 mm for this to work on my STAR), then the user can upload a new copy of the labware file definition and submit a pull request, which then gets re-validated by a separate user. I anticipate this will reveal some inherent differences between devices, but ultimately it will provide some peace of mind that what you’re using has been tested before in the manner you’re concerned with.

2 Likes

I’ve closed the poll and sent a Zoom invitation for the least bad time (Sept 6th at 2pm US Central) via email to everybody who took part in the poll. If you want to attend and did not receive an invitation, please let me know and I will add you.

2 Likes

I recently had this conversation with an employee from a liquid handling company and they said that this had been discussed internally before.
One problem they mentioned is that it once happened that a manufacturer decided taking off a layer from their labware and the labware definition wasn’t valid anymore. I suppose there had been no warning or mentioning of that. And that’s dangerous.
So it seems such databases will have to be used with care and, as many of us sugguest, entries should be peer-validated. It’s also important to annotate the validation dates.

1 Like

Another edge case to consider. I’ve seen deepwell plates of the same catalog number, but one lot is manufactured in the UK and another in China, have wildly different Z heights. So being able to version or annotate would be helpful in weird cases.

5 Likes

Wow. I don’t know what to say about that. We’re dealing with standardization and this is still an issue. Good hint.

1 Like

nightmare fuel lol

1 Like

This happens a lot. I learned a lot about we manufacture consumables during the pandemic.

1 Like