Missmatch in DeepWell_96_plate carrier definition

I’ve been trying to use a DeepWell_96_plate with my Tecan, but I think the carrier definition doesn’t make full sense. It mostly matches FreedomEvo interface, but for me the Well definition is odd.

Correct me if I am wrong, but the area is basically the well area right? Looking at PLR code, it consider the well as a cylinder per default and then uses the following formula to calculate a Well volume:

 max_volume = math.pi * (size_x / 2) ** 2 * size_z

However, with a size_x of 9 mm (as defined in DeepWell_96_Well definition), this will results in something closer to 64 mm^2. Is there something I don’t understand on PLR? Shouldn’t size_x and size_y be around 6.5 mm (to match Freedom Evo area)? That might also explain some issues I have with the position of the tip on that plate.

1 Like

Hi @delfoxav,

Unfortunately I don’t have a Tecan, so I haven’t worked on the PLR implementation for it.

But from a modelling side:

This is definitely incorrect:

def DeepWell_96_Well(name: str, with_lid: bool = False) -> TecanPlate:
  return TecanPlate(
    name=name,
    size_x=127.8,
    size_y=85.4,
    size_z=39.0,
    lid=DeepWell_96_Well_Lid(name=name + "_lid") if with_lid else None,
    model="DeepWell_96_Well",
    z_start=1670.0,
    z_dispense=1690.0,
    z_max=2060.0,
    area=33.2,
    ordered_items=create_ordered_items_2d(
      Well,
      num_items_x=12,
      num_items_y=8,
      dx=9.9,
      dy=6.7,
      dz=0.0,
      item_dx=9.0,
      item_dy=9.0,
      size_x=9.0,
      size_y=9.0,
      size_z=39.0,
    ),
  )

→ a well of a 96-wellplate cannot be size_x/y = 9 mm (diameter) because with a 9 mm distance between wells there would be no walls of the wells and therefore no wells :slight_smile:

I can see that the Tecan plates have also not been updated to the standard PLR wellplate nomenclature: see Corning-Falcon Plates as an example

But I can also see that TecanPlate requires some extra information that I don’t yet know about :slight_smile:

yes you are correct. please submit a PR for it if you have time!

in general we now avoid generic names like “96 well deep well” plate and other vague concepts like that, preferring to build a library of actual plate definitions with part numbers. I think over time we might want phase out DeepWell_96_Well because it’s just not clear which resource it refers to, and almost certainly requires offset to make it work. A problem with the tecan definitions is they have their own mystery attributes like “z_start” (explained here: PyLabRobot Tecan Error in adding labware to Carrier - #4 by evwolfson - PyLabRobot Development - Lab Automation Forums). In an ideal world we just have one complete physical definition of a plate that captures all information that any robot can then use. For this we would have to figure out how the derived properties like z start are computed from physical reality. See this GitHub issue for more information on that: Remove Tecan-Specific Attributes from resource model · Issue #552 · PyLabRobot/pylabrobot · GitHub

But yeah in the meantime fixing the well size attribute is the way to do it.

(also, DN simplify tecan coordinate system by nedru004 · Pull Request #581 · PyLabRobot/pylabrobot · GitHub WIP by @david.nedrud for refactoring the coordinate system)