As suggested by @CamilloMoschner, we really need to move to a standardized naming convention for the PLR labware library. Current names are imported along with the info from various other labware libraries, but that’s importing manure.
~I created a GitHub issue for discussion: Standardized labware naming conventions · Issue #157 · PyLabRobot/pylabrobot · GitHub. ~
Use this thread for discussion.
Camillo did a great proposal.
Please share your thoughts!
Thank you @rickwierenga,
I will reply here because I think more people tend to see the forum posts, and I prefer the forum’s search functions.
I propose we don’t invent too much new nomenclature but instead learn and cherry pick aspects of naming conventions from various companies based on what makes sense by first principles and is intuitive.
In PR#156 I have added the following Resource subclass overview to pylabrobot/resources/README.md to guide our nomenclature:
Standard Resource subclasses include:
Deck *****Carrier: provide multiple spots subresources in a well-defined layout *****
TipCarrierPlateCarrierMFXCarrierTubeCarrierContainer: contain liquids *****
WellPetriDishTubeTroughItemizedResource: contains items in a 2D layout
Plate *****TipRack *****TubeRack *****LidPlateAdapter *****MFXModule *****I think it likely that each of the subclasses I highlighted with asterisks will require their own naming convention.
Specifically, this would mean we have to develop standardized naming conventions for:
Deck *****Carrier: provide multiple spots subresources in a well-defined layout *****Container: contain liquids *****Plate *****TipRack*****TubeRack *****PlateAdapter *****MFXModule *****There is also a question regarding establishing a PLR machine nomenclature convention.
Question: A small but important one, do we want to call this catalog “PLR Labware Library” (similar to Opentrons) or “PLR Resource Library” (to reflect the broader scope of items covered and their underlying data type)?
(In my experience, a clear, consistent nomenclature facilitates definitions, exchange and use of resources)
Starting with the relatively easy one: As usual, Opentrons is spearheading logic, consistency and user-friendliness with their Labware Library, and I used its nomenclature to inspire this proposed convention for PLR:
e.g.: Cos_96_DWP_2mL_Vb
It differs from Opentrons API language in…
I think the well-bottom geometry is really important to have in the name but I am not sure about whether the proposed level of detail is needed for the plate_type. Opentrons simplifies this by simply using “wellplate” or “reservoir” in its place.
One thing to mention in regards to Opentrons is that their API takes these plate names as a string to the general method protocol_context.load_labware("biorad_96_wellplate_200ul_pcr", "1", "DNA plate").
That means plates are not defined as in PLR (i.e. as a function that defines a specific Resource subclass), but instead the information appears to be called from the API using the labware “name” as a string.
This explains why PLR labware names should start with a capital letter (they represent a class) and Opentrons API labware names are all lower case (they are just a string).
I am not sure whether the Opentrons API has to perform a wildcard import of all labware definitions stored in their database to achieve access to their labware information midrun or uses the names of labware as hashkeys to selectively import only definitions that are needed (?).
The wildcard import is not a reasonable approach for PLR because it hosts a much larger set of resource definitions from not just one automation company but many.
This one is quite a bit harder:
Opentrons machines don’t have carriers, Hamilton and Tecan do.
I don’t know anything about Tecan carriers yet.
Here is my attempt at figuring out what is going on with Hamilton carrier naming conventions (I might be wrong, and there is almost certainly information missing; information extracted from the folder shared by Eric):
e.g.:
TIP_CAR_480_A00PLT_CAR_L5AC_A00SMP_CAR_32C12_13x95_A00MFX_CAR_L5_baseRGT_CAR_3Rand some questions to raise about this nomenclature for PLR adaptation:
I hope this shows that there is quite a bit to discuss on Carrier nomenclature.
A valid question would also be whether it is easier for people to transfer from a proprietary control software to PLR if the naming is the same. I would argue no, because PLR should have a naming convention that is consistent internally, intuitive, and based on first principle decisions.
I have some ideas for the other Resource subclasses but simply chose these two (Plate, Carrier) to start our discussion.
Note: I suggest adding unit tests to flag new resource definition submissions that do not follow the PLR naming convention - if we want to enforce consistency as opposed to recommended “best practices”.
I will tag some people who I would like to ask for some recommendations and opinions in this process:
And of course, @rickwierenga 
Please feel free to add more people (apparently one can only mention up to 10 users in a single post). I think this should be an open discussion as it affects all PLR users. And many of you have extensive automation experience with valuable insights into what nomenclature has worked well for you.
i think MFX carriers are a big part of many workflows, some including custom-fabricated carriers with no pre-existing definitions.
the process for defining this geometry should be documented, and this will accelerate lots of work
not sure if we should save every permutation of the MFX carrier with its own name, or write a higher level util for quick MFX carrier setup. both work!
@ben, do you mean…
In case you meant 2: I have added the MFXCarrier class into PLR with PR#71, and have since then added the only two types I have come across:
MFX_CAR_L5_base (188039) → the “standard” MFXCarrier, 6T widePLT_CAR_L4_SHAKER (187001) → the “standard” carrier for machines like the HHS and HHC, 7T wide(funnily, the LVK carrier is technically also a 7T MFX carrier but has different hole locations, but I’m not using that carrier so I haven’t added it)
As can be seen by this example again: The naming is quite inconsistent. Both of the mentioned carriers are designed to flexibly exchanged “modules”, making them “mulit-flex” (MFX), with the modules being either of type plate, tiprack or machine.
Rick and I discussed this when I added the first two MFXModules in PR#77 which are…
MFX_TIP_module (188160)MFX_DWP_rackbased_module (188229)We concluded that adding every permutation possible (or allowing users to add them) would create an explosion of MFXCarriers because there are at least more than 30 different Hamilton-sold MFXModules, i.e. 30**5 possible combinations 
(not including in-house designed and manufactured MFXModules)
If someone wants to store their specific MFXCarrier configuration they can just write it up in a function themselves very easily for reuse purposes.
Ooof @CamilloMoschner do you use Figma or Figjam? I wonder if we can create a nice set of collab document to iterate over them in a more visual format.
The Tecan Fluent does some things differently and it would be interesting to see all of the major OEM providers setups mapped.
A couple things that came to mind randomly (may be a digression from this broader discussion, ignore if so):
How do “under-deck” modules (not sure what to call them) fit into this? I don’t have a lot of personal experience with these, but I know there are modules that fit “on” a deck by actually replacing a chunk of deck to accommodate large power supplies, heat sinks, or whatever. I know the Opentrons Flex does this, and I’m pretty sure some exist for Tecans and Hamiltons.
The other thing I will throw out is inclusion of SBS tube racks (e.g. Thermo Matrix, LVL, etc). These are functionally similar geometry to a deep well plate, but can have secondary considerations like incomplete racks, etc. Are these defined under TubeRack? If not, then perhaps worth considering something like:
Cos_96w_DWP_2mL_Vb (Costar 96 well plate)
LVL_96t_TRck_2mL_Fb (LVL SBS tube rack)
No specific comment right now on the broader topic, as it seems to make sense upon a quick read through. Will continue to consider.
I think this is a great idea, and exactly how I like to work as well.
No, I don’t know how far their free plan can get us?
I think in the open-source spirit of PLR, we should stick with an open-source alternative.
Do you think this simple Google diagram board will be able to do the job?
I completely agree. One of the many fantastic things about PLR is its cross-manufacturer support. It is very important to maintain that.
I know essentially nothing about how Tecan does things, and am very keen on learning more.
(Oddly, I literally bump into Hamilton application scientists in our research campus gym, yet have never even had the chance to speak with a Tecan employee )
I usually call these simply “off-deck” machines because these could be located anywhere in relationship to the main liquid handler (i.e. behind, below, right, left, front, atop).
I would assume companies like Automata have standardized names for this though?
I don’t think this is a problem for PLR even right now:
PLR uses a cartesian coordinate system for all machines with the origin (0,0,0) at the front-left of the machine (@rickwierenga, as always, please correct me if I’m wrong).
Hamilton machines are are bit odd in that the front-left actually starts at (0,0,10), i.e. it thinks that there are 10mm of space below the deck. When I asked a Hamilton employee why, they told me this is exactly for below-deck space allocation… but when I took a STAR apart I found the space to be blocked and unusable 
But I know you can buy e.g. a Vantage with additional below and behind usable space.
In these situations, i.e. where there is additional space in the liquid handler - not a separate, connected machine system, I think it makes sense to still reference the machine origin, i.e. go into negative z-coordinates.
But I guess in the end it all depends on the firmware commands the machine uses to move resources in/out of the deck.
We actually had short conversation with the user of a beefy Vantage here on the forum just yesterday. @sclarkson, could you please share some insights into what coordinate information the Trac gripper uses to move labware in/out of the Vantage?
Yes, PLR should be able to cover these already. @rickwierenga and @Stefan designed a very flexible and easy-to-use definition system.
(I haven’t added my Thermo Matrix definition yet, but there is a simple “Defining a custom plate” tutorial in the PLR docs already that can easily be used to deal with it)
Not sure if this has already been accounted for, but per my understanding the MFX carrier is just the general “whatever” configuration carrier. There’s a special editor available to create these and the names are generated based on what modules are in use.
It can be found at “C:\Program Files (x86)\HAMILTON\Bin\LabwareAssistant3D.exe” if it’s installed - otherwise I’m sure it’s in the Hamilton method fileshare.
There are some typical configurations, but similar to Tecan segments there’s no absolutely standard setup for these carriers.
Hi all, if one of the goals of the convention is to aid in lookups (linking a piece of labware you have available to a definition that may or may not exist in the PLR standard library), then I think it could help to include the manufacturer’s reference number somewhere. @CamilloMoschner mentions the part reference numbers here, and so does Opentrons in their labware library, so the utility is evident in my eyes.
@evwolfson Yes, the fact that the Labware Assistant 3D software only shows 4 MFXCarriers means PLR should not have more than those “base” MFXCarriers.
I have contributed two of these to PLR:
MFX_CAR_L5_base (188039)PLT_CAR_L4_SHAKER (187001)And additionally have added two MFXModules so far.
You can find a summary of these, including their Hamilton cat numbers (so people can actually buy them), explanations and a Labware Assistant 3D-generated image for visual guidance on the pylabrobot/resources/ml_star/README.md.
If people have more MFXModules please consider contributing definitions to the PLR Resource Library.
Labware Assistant 3D is very nice, especially the semi-3D viewport. But its a hassle to get new or self-designed MFXModules in there, and going back and forth between different programmes is less than ideal. Also having no version control tracking modifications to the definitions one might make, plus… being forced to work with Windows
PLR is much simpler than going into the Labware Assistant 3D → export → place files in the correct Hamilton folder → open VENUS → add files → place on deck position → verify.
Instead you can just write
mfx_carrier_1 = MFX_CAR_L5_base(name='mfx_carrier_1')
# Assign DWP_modules
mfx_carrier_1[0] = DWP_module_1 = MFX_DWP_rackbased_module(name="DWP_module_1")
mfx_carrier_1[1] = DWP_module_2 = MFX_DWP_rackbased_module(name="DWP_module_2")
# Assign TIP_modules
mfx_carrier_1[2] = TIP_module_1 = MFX_TIP_module(name="TIP_module_1 ")
mfx_carrier_1[3] = TIP_module_2 = MFX_TIP_module(name="TIP_module_2")
mfx_carrier_1[4] = TIP_module_2 = MFX_TIP_module(name="TIP_module_3")
…and modify it to your liking.
(edited: little note of caution: PLR is based on logical numbering, i.e. carrier position numbers are going with the machine’s cartesian coordinate system, i.e. the front-most position / closest to the user and the machine origin is position 0 and the one in the back of the machine / furthest away from the user is position 4 - this is using 0-based indexing, as it is code, and the numbering direction is the opposite of Hamilton’s numbering convention)
If you just need an Lkey and 3 minutes to physically build a new MFXCarrier I think generating its digital definition should take no longer. 
Please give suggestions on what you guys think a sensible naming convention for MFXModules could look like.
Hi @fderop,
Welcome to the forum!
(A little explainer for the following: In PLR all physical objects are computationally defined as a Resource instance [see pylabrobot/resources/resource.py], and if they require special information are then further defined as a specific subclass of Resource, e.g.: Deck, Carrier, MFXModule, …)
I completely agree with your point: Part of the naming convention is aiding lookups and facilitating actually using labware.
I always find it quite frustrating when a protocol (manual or automated) uses consumables, reagents, machines, yet I cannot find out what the catalogue number is that they got it from, i.e. the information to reproduce a setup.
(I think this is the time where should say that I am not sponsored by any of the companies whose products’ information I make readily available in PLR, therefore giving them “free advertisement” of a sort )
However, with PLR I found …
Resource name diminishes readability of code very quickly and should therefore be avoided, andPoint 1, I’ve momentarily addressed the availability of Resource’s catalogue numbers by simply adding them…
Resource’s docstring, andResource is defined.E.g.: see pylabrobot/resources/thermo_fisher/README.md and the corresponding definition:
def ThermoScientific_96_DWP_1200ul_Rd(name: str, with_lid: bool = False) -> Plate:
""" Fisher Scientific/Thermo Fisher cat. no.: 10243223/AB1127.
- Material: Polypropylene (AB-1068, polystyrene)
- Sterilization compatibility: Autoclaving (15 minutes at 121°C) or
Gamma Irradiation
- Chemical resistance: to DMSO (100%); Ethanol (100%); Isopropanol (100%)
- Round well shape designed for optimal sample recovery or square shape to
maximize sample volume within ANSI footprint design
- Each well has an independent sealing rim to prevent cross-contamination
- U-bottomed wells ideally suited for sample resuspension
- Sealing options: Adhesive Seals, Heat Seals, Storage Plate Caps and Cap
Strips, and Storage Plate Sealing Mats
- Cleanliness: 10243223/AB1127: Cleanroom manufactured
- ANSI/SLAS-format for compatibility with automated systems
"""
return Plate(
name=name,
size_x=127.0,
size_y=86.0,
size_z=24.0,
with_lid=with_lid,
model="ThermoScientific_96_DWP_1200ul_Rd",
lid_height=5,
items=create_equally_spaced_2d(Well,
num_items_x=12,
num_items_y=8,
dx=10.0,
dy=7.3,
dz=1.0,
item_dx=9,
item_dy=9,
size_x=8.3,
size_y=8.3,
size_z=20.5,
bottom_type=WellBottomType.U,
cross_section_type=CrossSectionType.RECTANGLE,
compute_volume_from_height=_compute_volume_from_height_ThermoScientific_96_DWP_1200ul_Rd,
compute_height_from_volume=_compute_height_from_volume_ThermoScientific_96_DWP_1200ul_Rd
),
)
…and I added some additional information that is very useful to know and purchase decision pointers like [material, sterilization_compatibility, cleanliness, chem_reistance, temp_resistance, automation_compatibility, ...] … really depends on what info the manufacturers actually make available.
If I am the only person contributing information in this detail that’s okay but it will mean a lot of wasted time for users and slow growth of the PLR Resource Library.
Therefore I would like to ask more people to contribute Resource definitions and their documentation to PLR (if anyone is unsure about how to do so, I am happy to help with that).
…
Do we think we should make this “resource_metadata” into optional Resource attributes?
What do you think, @rickwierenga and @ben?
Some plates haven’t changed in decades, i.e. the information half-life could be worth the effort of PLR integration.
Point 2, I found no way around this and lookup the manufacturer information of everything I purchase and use anyway
thanks Camillo for taking the lead here 
I think Resource library is best, because it’s broad and because the base class in PLR is already called Resource.
I agree. I used to want to adhere strictly to specifications provided by other people, seen in the way STAR is set up and the way resources are named, etc. But to match this project’s ambition we should go from first-principles.
Agree for resources in a well-defined set of libraries. In the general case, as a general principle, we should be flexible, and only constrain on what is physically impossible.
Also, responding to …
… this naming guide should apply to well-defined set of resources (eg plates, tip racks, etc.). As suggested by Camillo, each Resource-category (plate, tip rack, etc) will have its own guide. Odd resources can still have odd names.
It is something we already do, for example with the plate reader.
This is just wrt the liquid handler.
Nothing prevents you from assigning the LiquidHandler itself to a higher level object like Lab or Workcell in an encompassing coordinate space. (actually, get_absolute_location may prevent you, but I want to refactor that to get_absolute_location(in:))
As you mention, Camillo, people can also have separate coordinate spaces that are not connected to that of LH.
What is the difference between these? Why is not every plate a multi-well plate?
Yes, Opentrons stores all information in JSON and loads it using identifiers. See opentrons/shared-data at edge · Opentrons/opentrons · GitHub.
PLR labware is actually defined as functions, that return an instance of a class 
(they used to be classes, a long long time ago.)
I would define Plate as all 2d-grid, single-piece plastic resources. If the “wells” are removable, I think they would be tubes, and then the rack is a TubeRack. TubeRacks should be able to miss tubes.
About the “version” part of the name (A00, A01): preferably we reach a consensus resource in PLR that works for everyone. If this refers to version of resource definition (with a fixed underlying resource), I agree we should just keep the latest version.
But what if a manufacturer has two version of the carrier with the same specifications? This could be a new version of a product they already have. In that case, perhaps PLR should add V2 etc.?
Definitely.
We should have “building blocks” that you see in the MFX program (camillo has already contributed two), but construct the higher level “module” at runtime. I guess in a way this is similar to other resources in PLR, which are just classes instantiated at runtime.
I mean to say this is different from the hamilton MFX program, which exports specific definition files for each configuration. Not a problem for specific users, but not a general solution for us.
Thanks Camillo for illustrating the niceness of this with code.
+1 on Florian’s searchability.
Unless meta data is needed at runtime, I think this information should go in the documentation. I am not a huge fan of resource_metadata tbh, because it’s not a functional or readable field. This documentation can be in the doc string (useful!) and extra information can go in supporting files.
I believe this documentation should exist on the website (docs.pylabrobot.org) in addition to the README files Camillo has been making.
Actionable todo for me:
pylabrobot.resources submodule and copies all README files into the docs folder. They will then be included in the HTML exports.Perfect, then I will try to only use this term, and the pylabrobot/resources/README.md documentation is already named like that as well
I understand; so we do not want to make any naming convention compulsory but only have recommended naming conventions?
Absolutely love this and can’t wait for the refactor
That is an excellent question… this is taken from Hamilton nomenclature.
I guess there is a point to saying this is closer to everyday-language in the lab where DWP is a common acronym, but there is a reason why Opentrons seems to have chosen against his nomenclature.
My best guess is, like you mention, every plate is a wellplate (as Opentrons puts it).
I also had to dig quite a bit to find somewhere that gave the arbitrary distinction of “micro-titer plate” [=<500ul].
Okay, let’s remove _MTP_ and _DWP_ from the discussion board.
Next question: Should we then simply adopt the Opentrons plate naming convention and add the bottom type to the end?:
e.g.: ThermoScientific_96_wellplate_1200ul_Rd
Should manufacturer abbreviations be acceptable?
e.g.: Cos_96_wellplate_2mL_Vb (instead of Costar_96_wellplate_2mL_Vb)
That’s why I wrote “represent”, i.e. I meant the capital letter of the function represents the data type it returns
I agree. Do you think we should remove sample and reagent carriers, @rickwierenga ?
Sample carriers (i.e. carriers for tubes) are even in VENUS defined as racks and I am inclined to do the same in PLR, i.e. make them TubeRacks.
Reagent carriers… I am not sure. All these should be able to do is take Troughs / reservoirs as children in pre-defined sites.
You are welcome. You guys created a wonderfully simple and fast definition system here.
@evwolfson, you might not want to explicitly declare all of this every single time you write a new protocol.
PLR got you covered here too. The above example of a carrier instantiation can also be stored wherever you want as…
def special_carrier():
mfx_carrier_1 = MFX_CAR_L5_base(name='mfx_carrier_1')
# Assign DWP_modules
mfx_carrier_1[0] = DWP_module_1 = MFX_DWP_rackbased_module(name="DWP_module_1")
mfx_carrier_1[1] = DWP_module_2 = MFX_DWP_rackbased_module(name="DWP_module_2")
# Assign TIP_modules
mfx_carrier_1[2] = TIP_module_1 = MFX_TIP_module(name="TIP_module_1 ")
mfx_carrier_1[3] = TIP_module_2 = MFX_TIP_module(name="TIP_module_2")
mfx_carrier_1[4] = TIP_module_2 = MFX_TIP_module(name="TIP_module_3")
return mfx_carrier_1
special_carrier_instance = special_carrier()
lh.deck.assign_child_resource(special_carrier_instance, rails=14)
…and then simply imported into your protocol as a pre-designed carrier configuration
But as Rick said, PLR is giving the “building blocks”, due to the combinatorial explosion of MFXModules available, it is up to users to create these special configurations themselves and import them / define them as users want.
I understand, and agree on the runtime need part and that therefore I agree this information is not needed as a class attribute.
I can write a docstring guide that includes a template for different Resources to accelerate information addition to new definitions by users.
That is a fantastic idea. Thank you, @rickwierenga!
I have had a couple of occasions where I was interested in a VENUS-originated plate definition, but I had to abandon using it because I could not figure out what manufacturer and/or catalogue number it was.
These definitions are therefore arguably wasted code space.
Documentation that associates every Resource definition at least with its manufacturer and catalogue number will prevent this from happening in the future.
Compulsory for a subset of the library is best I think.
Sounds very useful, and avoid naming collisions.
Abbreviations?
fair
Until this point, I think the distinction was that Carriers slide in the rails and racks go on the deck or on carriers. But I’m happy to drop this convention.
Sure. If we can simply keep them as Carrier, that is best.
That would be nice. Do you think you could contribute this to the resources doc: Resources Introduction — PyLabRobot documentation?
so you did have the physical resource? why were you interested in this definition?
I guess we can define the naming conventions first and then decide which ones are supposed to be compulsory?
Yes, do you think abbreviations should be allowed? (Maybe if we agree and state the abbreviation in the README?)
I’m fairly relaxed with this one. Tbh keeping Carrier as a Resource that slides onto the deck seems very intuitive and reasonable to me.
I just don’t think “sample” and “through” carriers make sense since they are both containers.
I interpreted Carrier more as a superclass. Should we then create a ContainerCarrier that covers tubes and throughs/reservoirs?
Sure, I need to get back into figuring out the docs contribution, so might take a bit of time.
Yes, once I had the physical resource, thought the VENUS definition I found matched it but then the bottom type was different even though the remaining definition seemed correct. I don’t take risks and simply created a new definition.
Another time I was searching for a plate with certain specifications. To my knowledge there is no online database of plates across manufacturers that one can query for certain plate attributes.
This is a bit of back-of-the-mind plan for PLR tbh: Writing a parser for the PLR Resource Library to identify queries either from the class attribute or the docstring is pretty easy
I think that’s best, assuming we have a clearing mapping in a table.
I have seen these carriers (I believe sample carriers) where tubes slide in.
Looking at this random picture from Google, I think it makes sense to keep both as carriers, if we define carrier=‘slide in rails’-resource.
The carriers will have Tubes and Troughs as children.
A largely inconsequential discussion, but I think it’s good to have them as separate classes since they seem quite distinct.
Simply change the files in the /docs folder and run make docs. I find the sphinx documentation to be confusing, so I always ask Chat. Please create a thread if anything is inintuitive.
how did you find it?
This seems similar to what Mark Doerr at the University of Greifswald is working at: GitHub - Bioprotocols/labware-databank. We should look into collaborating. I am calling with Mark this Thursday again at 5pm CET, you should join!
Definitely!
I did not even consider a distinction between the two, that’s a really good concern to raise. I’m not super familiar with the world of labware, but have there been instances where a supplier changed the manufacturer of a part without updating the associated supplier ID of the product?
Yes, this seems reasonable.
This would be massively useful I think. Thank you both!
Okay, then this means we keep all standard carrier prefixes as separate just like Hamilton does?
i.e.
What do you think about the labware_info section? Is this the most efficient way to incorporate the information?
Standardisation is very important to accelerate development speed and not get lost in a sea of different names for the same item. I don’t mind that much what the final standard is but will just keep pushing for standards
That being said… how is this different from how Tecan and Beckman Coulter names their liquid handler’s labware?
I wonder whether carrier naming could be consistent between them for PLR?
Complexity-wise I can just think of these two as having comparably complex machines that are or might soon be integrated into PLR.
Going on a manual code hunt through the resources plate.py files 
Ohh this comes out of an iGEM project
Unfortunately, I can’t make that time.
This conversation brings to mind another feature that may be worth stating for each carrier - barcode reader compatibility. Hamilton has the Autoload, Tecan has the PosID/FluntID, Beckman has fly-by readers, but as far as I understand they all do barcode reading slightly different.
In terms of complexity, fly-by barcode readers (abbv:FBBR static mounted or on gripper/labware) are likely the top-level of barcode integration (outside handheld-reader) which require some sort of instruction to move plates to the reader as an intermediate step. This is related to the labware itself so the only relevant info would be, “does this have a 2D barcode?” and “can I pick the labware up?”
Next up would be something like the AutoLoad, which moves the entire carrier in order to read barcodes. I haven’t used this system enough to know if there are specific carriers for this or if all Hamilton carriers are default compatible.
Third would be Tecan with the special equipment once again - EVO has the PosID and “runners” similar to above carriers to scan tubes and plates in specific carriers, but not every carrieris compatible. The Fluent switches things up again with the FluentID that requires manual movement of the runners during deck setup - once again with specific carriers.
I won’t speak for the entire gallery, but I imagine barcode/no barcode should be includedinto the labware definition somehow - maybe as a “_BC” suffix for applicable labware. To add constraint, it might be ideal to limit current barcode functionality to just FBBR since these are universally compatible for all mfr/models as static installed or handheld utilities.
On the Tecan side of things, my experience has been total anarchy. Tecan provides basic SLAS/ANSI definitions for a few labware like 96DW, 96MTP, 96PCR, etc… then recommend users create a copy and customize as required. The assumption (as best I can tell) is that it’s expected that labs stick with one or two specific brands/types of labware and knowing make/model isn’t specifically necessary outside of SOP/MBR/Ordering. Mfr, part number, etc have designated fields within the labware description as additional characteristics, but typically do not make their way into the labware name unless the engineer deems it necessary.
BCI is similar - user driven labware so no uniformity that I’ve seen.
Project Labware database
