Database storing common Labware (DWPs, etc.) specifications

For hosting a static site backed by Github, check out Netlify CMS :slight_smile:


Is anybody aware of a free/open-source online tool for generating collaborative database relationship diagrams? I would sugguest we start at creating a draft after we have had our first Zoom call next week.

1 Like

We can also use github pages (


1 Like

Here’s an example of a site hosted on github pages that has some filtering. The way you can represent and filter objects is virtually unlimited though—it can be anything in Bootstrap / javascript. Likely any way you’ve seen on the web that can filter and display results would be compatible. Who’s using GitHub? | GitHub and Government


I agree, peer review would be essential. And since this community is growing quite fast, at least from the amount of information shared in this forum in just over a week, my feeling the community would really collaborate to check they are accurate.

I have had exactly the same experience.

1 Like

That’s very pleasing :heart_eyes:

Hello, all: we had a very productive scoping discussion yesterday and are planning to meet again next week to start making technical decisions.

For this purpose, the group meeting yesterday is planning to use the Bits in Bio Slack, where there is now a #collab-labware-database channel dedicated for this purpose.

Public Slack invite: Slack

1 Like

You cant google a slack channel…

Stay strong for googlable automation progress!

That slack channel can come out from behind the “invite curtain” and discuss here.

1 Like

I reached out to Jonathan Bloom about this and hope he comes around on this topic. An active Slack channel is great to have for established tech fields. There is no problem with the myriad of ML, Data Science, Specific programming language, or any other computer science related field. This is because at the end of the day, the day to day for people in this industry is to google their problem, head to stack exchange or random web page openly published, get quick solution, run tests, commit, rinse and repeat.

Then at the end of the day go to their community Slacks, Discord, etc and talk about community building, planning, etc. Sometimes people reach out to specific community channels if is the case where they can’t find their problem on the open web.

Now I think it’s fair to assume that along the way for this database discussion and implementation we as engineers will post, answer and discussion nuances of labware issues in automation. I think we all would agree if we at day one in this industry could get just one hit on google we’d have just a little less grey hair.

So for the new generation I beg to not go the route of Slack. Whether they are public or not. The simple act of having to know some one to send an invite to a “Public” slack channel immediately reduces about 99% of visibility.


I agree with @smohler, unfortunately I couldn’t make last night’s discussion but I too have the same worries. Slack is for communication but not for storage of definitions like this. Github or something like this is the best way forward- it is peer reviewed, versioned, public and searchable. It also exposes public URLs for downloads that can be used in scripts etc.

As I said, Slack is fine for communication and organisation, but surely it would make sense to have a subforum here for that purpose here?

I believe my earlier communication was insufficiently clear. I agree with everything said about open community processes and the importance of durable records. In my experience, it is also valuable to have different fora for different “speeds” of communication.

  • Synchronous meetings for in-depth tech wrangling
  • Instant messages (e.g., Slack) for organization & chat
  • Durable open list / forum (e.g., here or a google group) for technical discussion, announcements, and community building
  • Git or similar for actually maintaining any open technical artifact (code, data, or other)

The Slack channel is for getting things coordinated as a group; beyond that is all still as yet unformed.


Don’t forget or thelike for generating database relationship diagrams or diagrams in general!

1 Like

This is an interesting topic for Genie Life Sciences because it’s something we’ve been discussing and, as time permits, working towards. Even though we manufacture our own liquid handler, it’s always been our goal to keep our software platform instrument agnostic, so we can run the same protocols on various liquid handlers. One of the things this, of course, requires is an instrument agnostic labware definition. One of Genie’s components is the “Catalog Service”, which stores all labware (plates, tip racks, tubes, tube holders, lids, risers, magnets, etc.), including height rules on labware stacking. We’re a SaaS platform so whenever we publish a new labware, it’s immediately available to all customers. We’ve also successfully translated our labware definition to other liquid handlers (if your model is decent, these transformations are typically very easy to do).

The question I am now asking myself is whether we should enable open access to our Catalog Service so others can post new labware and download existing labware. It’s some work for us, but if there’s a true demand for this it’s really tempting to just do.

In either case, from my experience, here’s what is needed for a good labware model:

  • Dimensions, wells, well depth, tip minimums and maximums, etc. are all a given. I’ve looked at several models in the past and most vendors do between an OK and pretty good job at this.
  • Irregular labware support. Not everything is an N by M grid and not all wells have the same depth.
  • Estimated liquid level (e.g. if I have 20 ul in the well, what is the well offset). There was some discussion about this. The approach we took is to have a lookup table. It’s as reliable as you want it to be and definitely much more reliable than a math function since wells don’t always follow a perfect geometric shape.
  • Camera support (mostly because GLS has a built-in camera)
  • Stacking rules. When you put labware A on labware B, the combined height is not A+B.
  • Accessibility constraints – this is a really annoying one because it’s liquid handler specific, but some liquid handlers cannot access some wells with some of their channels when the plate is in specific deck locations (e.g. first row).
  • Gripper support (we didn’t do this yet because we haven’t had any trouble determining the right offset algorithmically as a function of the labware height)
  • Versioning. People may adjust labware definitions over time (e.g. they made a mistake) but if you’re already using the old definition, even if it’s broken, you don’t want to get the newest definition without explicitly choosing to update to a newer version. Without versioning the service’s reliability is lost.

I also believe that a cloud service is a far better way to go than a static repository. People should be able to publish labware definitions publicly (anyone can use it) or privately (only their company can use it). It would be good to have usage counts or ratings of some kind to indicate the maturity of a labware’s definition. Kind of like what npmjs is for JavaScript libraries.


Please do make your catalog available under a FOSS license!

As a community, we really need to be able to unify and harmonize across the disparate catalogs being built by you, by OpenTrons, by Strateos, by ECL, by etc., etc.

I see cloud vs. repository as a false dichotomy - if you have a good representation, you can have an integrated approach with views in different formats, as is often done with biomedical ontologies. In every case, however, there is a necessity for some sort of version control and review process.


It would be good to have usage counts or ratings of some kind to indicate the maturity of a labware’s definition.

I think peer review is the term here that we need to adopt. Here’s a definition that we’ve found to be optimized pretty well for this range of volumes and it has been tested and used by X,Y,Z.

Something this small can go a long way toward democratizing our shared knowledge.

1 Like

Excellent comment. I think that many if not the most important problems are mentioned here.
I was wondering, do you find disregarding well geometry and taking the lookup tables as you sugguest really that helpful? I assume it will be hard to standardize the offset measurement procedure: 1) The measured offsets will depend on the teaching accuracy, 2) liquid level sensing will probably not be instrument-agnostic and so the accuracies will also vary 3) liquid level sensing is not too accurate in the first place, is it? 4) laboratories differ in their “standard” temperatures and the same liquid will thus have different densities 5) and maybe other problems.

There’s automatic liquid level sensing, whether using conductive tips or air pressure. Most of my experience is with pressure based liquid level detection because that’s what the Genie liquid handler is using. I found it to be super accurate (as long as you don’t re-use tips). I suspect using conductive tips is also very accurate (note that it doesn’t work with some liquids) since a lot of the commercial liquid handlers use that technology. Good automatic liquid handling doesn’t, IMO, need any hints from the labware definition beyond maybe bottom of well and top of well locations.

The liquid detection I am referring to is “estimated liquid level”. If you know how much volume is in a well and the well’s geometry, it’s possible to estimate the liquid level. It will not as accurate as automatic liquid level detection, but it will be faster and is the right approach for some use cases. At Genie we automatically keep track of labware state (e.g. if you have a transfer that moves liquid from one plate to another, we automatically update the state of the labware with the amount of liquid that is removed and/or added) so using ELL is pretty simple without any additional work.

Here we need to start with some assumption about instrument accuracy. If the instrument, for example, cannot accurately move to well bottom + 1 mm, then things just won’t be accurate, regardless what you do. Our labware definition has a small lookup table of volume to offsets from well bottom, so for a particular well 50 ul may out you at 1.44 mm, 100 ul at 2.88 mm, etc. If a volume falls in-between an entry (e.g. 72 ul), then you just do a linear difference between the two points. The neat thing is that these tables don’t need to be large. If a well is fairly regular you’d only need 3-4 entries and if it’s highly irregular, then at most an entry per mm in height. I believe the overall accuracy of this approach is +/- 2mm (partly due to how it’s measured, whether the liquid level is bulging out or in, temperature, etc.).

We measure using water at room temperature. We measure using our liquid handler or, at times, by hand with an electronic pipette. Yes, all of these things have an aggregated affect, but it’s not an approach that will ever be perfect. You just need to acknowledge the precision of ELL, which I put at +/- 2mm.


As Denis said, this is something we’ve always wanted to do at Genie. It aligns very well with our vision for lab automation.

Is anyone interested in a virtual meet-up on this topic? We’d love to discuss what we currently have in our Catalog Service, and what people are looking for if we were to make this available. We want this feature to be as useable as possible for Automation Engineers, and rely on feedback for what’s expected/needed.

If anyone’s interested in a brief 30-min virtual meeting the last week of September, feel free to reply and I can coordinate!