Hamilton Mfx module 188049

[linx5o]

Following the discussion about not yet implemented modules. PLR Forum.

I have attempted to create a definition for a module I have on hand.

There are no cat. no on the module. I also do not have access to the purchase history.

From the VENUS four Operators Manual.pdf provided by Eric Sindelar (senior Hamilton employee) on the labautomation.io forum. There are two potential candidates.

This ebay listing suggests it is the prior. However, this other listing for 188042 more aligns with the image in the manual.

I therefore believe that this module should be 188049.

I have tested this module on the liquid handler. There are no errors and the height is correct upon visual inspection when using plates.

[BioCam]

Hi @linx5o,

I therefore believe that this module should be 188049.

I don't believe it is 188049 because...

...cat no 188049 seems to refer to a plate_holder without clamps or lips that has a plate_adapter on top of it?

[BioCam]

Would you be okay with posting a picture of this multiflex module please?

Then we can assess:

• Does it have metal clamps?

• You've named it "flat", does it still have a pedestal (i.e. central elevation)? It is possible to have a central elevation and it is still technically "flat" because the corners might also be raised: e.g. this can be kinda defined as "flat":
  
  (though technically there is still a small pedestal elevation that could destroy your fine-precision pipetting in this example 👀 )

• Or is the plate_holder top actually completely flat?

• And most importantly, does it have these small nodules on the side of the pedestal (if there is a pedestal)?
  

[linx5o]

Here are the images:


No clamps, just some guides. No possibility for central elevation either.

Some rough measurements of size. It is the taller module.

I do agree with your judgment. I have not been able to get LabwareAssistant3D.exe to work on my computer. There does not seem to be a lot of information online about these either. Sorry! I will keep trying to find a cat. no.

[rickwierenga]

found by @ben-ray:

[BioCam]

No worries @linx5o,

The pictures help a lot and we can figure this out :)

---

found by @ben-ray:

...I don't think it is this one because @linx5o didn't mention that his MFX module is sloped, i.e. has a rigid top surface with a tilt?

---

Investigation 🕵🏻‍♂️

This PR introduces the following resource definition function:

from pylabrobot.resources import PlateHolder, Coordinate
from pylabrobot.resources import (
    MFX_CAR_L5_base, 
)

def MFX_WP_module_flat(name: str) -> PlateHolder:
  """Hamilton cat. no.: 188049 (uncertain)
  Module to position a Well Plate. Taller version of MFX_DWP_module_flat.
  """

  # Resource size is carried over from MFX_DWP_module_flat.
  # Child location offset for x, y are measured with caliper.

  return PlateHolder(
    name=name,
    size_x=135.0,
    size_y=94.0,
    size_z=216 - 18.195 - 100,  # mesured using probe
    # probe height - carrier_height - deck_height
    child_location=Coordinate(3.0, 4.0, 209.9 - 18.195 - 100),
    pedestal_size_z=0,
  )

enruis_mfx_module = MFX_WP_module_flat(name="enruis_mfx_module")

mfx_carrier_test = MFX_CAR_L5_base(
  name="mfx_carrier_test",
  modules={
      0: enruis_mfx_module,
  }
)
lh.deck.assign_child_resource(mfx_carrier_test, rails=1)

print(enruis_mfx_module.get_absolute_location() + enruis_mfx_module.child_location)

>>>Coordinate(x=103.0, y=72.0, z=209.9)
# i.e. the origin (flb) of the plate_holder's child_location

Going through Labware Assistant 3D this seems like a good candidate:

(don't get thrown off by Labware Assistant 3D showing a metal top, I ordered sth I believed should have a metal top based on this .exe before and it came with a coated plastic top like your MFX module 🙃 )

How to check for the difference?

VENUS 4 is free to use and also shared publicly shared by Eric Sindelar on the labautomation.io forum.

One can use Labware Assistant 3D to generate an MFX_CAR_L5_base with 188228 in its front position, add it to a STARlet deck and check out the child_location like this:

--> difference between definitions for the plate_holder's child_location:

• @linx5o: Coordinate(x=103.0, y=72.0, z=209.9)
• VENUS, assuming cat no.: 188228: Coordinate(x=104.0, y=71.5, z=206.0)

Now, this doesn't have to mean VENUS is right, in many instances we found that VENUS definitions are more of a guide than an actual "ground truth", but usually that applies more to VENUS' plate/tube/etc definitions, not so much towards fine-machined metal carriers + mfx_modules.

@linx5o, do you think this adjusted definition could work for your purposes / test it?:

def MFX_WP_module_flat(name: str) -> PlateHolder:
  """Hamilton cat. no.: 188228
  Module to position a Well Plate. Taller version of MFX_DWP_module_flat.
  """

  # Resource size is carried over from MFX_DWP_module_flat.
  # Child location offset for x, y are measured with caliper.

  return PlateHolder(
    name=name,
    size_x=135.0,
    size_y=94.0,
    size_z=216 - 18.195 - 100,  # mesured using probe
    # probe height - carrier_height - deck_height
    child_location=Coordinate(4.0, 3.5, 206.0 - 18.195 - 100),
    pedestal_size_z=0,
  )

I believe your definition is close enough to the VENUS "ground truth" to make your definition refer to Hamilton cat. no. 188228 :)

[BioCam]

Note:

Might I recommend renaming MFX_WP_module_flat() -> Hamilton_MFXmodule_tall_flat()

(We haven't figured out a PLR naming convention for MFX Modules yet, but the first identifier should always be the manufacturer. So far we tried to avoid ambiguous terms like MTP [micro-tube-plate], DWP [deep-well-plate], WP [well-plate?]. Though a couple are still remnant from old times. I'm making this recommendation here in anticipation of what the naming convention might look like)

People who've been using these terms for decades usually say "ohh, these terms are standard in biotech" ... but at the same time acknowledge that this "standard" has different definitions for different people.
We therefore try to avoid them altogether in PLR and aim to replace them with unambiguous fully-written-out terms.

[linx5o]

@BioCam Could sloped be referring to the positioning guides along the side (The things that stick up to help guide the plate)? I can't really tell with 188228, but they don't seem to have a slope in them.

I also remeasured the sizes. My x for off. It should be 134.

I have used this definition for the last few days. No issues so far.

[BioCam]

@BioCam Could sloped be referring to the positioning guides along the side (The things that stick up to help guide the plate)? I can't really tell with 188228, but they don't seem to have a slope in them.

No, I believe you are referring to what some people call plate_holder "lips", this stuff:

"Sloped" refers to the fact that the top surface is higher on the right than on the left, usually by ~2 mm.
This gives every well a tiny tilt, helping with liquid recovery.
You can achieve the same thing by buying a "tilter mfx module" (which Rick, Ben & the Retro team did a lot of PLR work on).
But a tilter module costs a couple thousands, a sloped mfx plate holder costs max a couple hundreds.

@BioCam Could sloped be referring to the positioning guides along the side (The things that stick up to help guide the plate)? I can't really tell with 188228, but they don't seem to have a slope in them.

I also remeasured the sizes. My x for off. It should be 134.

I have used this definition for the last few days. No issues so far.

I don't understand what you mean by this. Could you please elaborate?
Your definition generates your plate_holder's child_location at Coordinate(x=103.0, y=72.0, z=209.9) based on the code I provided above (i.e. MFX carrier on rail=1, your MFX module in the frontmost position on that MFX carrier).

I have used this definition for the last few days. No issues so far.

There are many reasons why these slight differences between VENUS' "ground truth" might not have caused any issues:

--> difference between definitions for the plate_holder's child_location:

• @linx5o: Coordinate(x=103.0, y=72.0, z=209.9)
• VENUS, assuming cat no.: 188228: Coordinate(x=104.0, y=71.5, z=206.0)

x and y position are only 1 and 0.5 mm different, respectively... that rarely causes any issues with 96-wellplate usage (but might with 384- and 1536-wellplate usage?).
Plus, you mentioned in your comments inside your definition you measured these values using a caliper. Getting a caliper measurement to 1 and 0.5 mm accurate is very impressive!

Regarding z, during pipetting you might never find an issues here... until you do:

• If you used capacitive liquid level detection, it wouldn't detect the bottom of the well, but the liquid -> no problem.
• even if you pipetted to the bottom: your definition makes everything appear 3.9 mm higher than VENUS' definition, which means when you think you pipette to the bottom you are actually 3.9 mm above the bottom -> no problem, except if you try to pipette into empty wells with low volumes, because then you'll just generate a droplet on your tip that has no surface in the well to adhere to.

The big question for me: Have you used your iSWAP to transport a plate to this MFX module?
If yes, have you noticed the iSWAP dropping the plate slightly above (by about 4mm), not enough to cause any issues (after all it is already right above where the plate needs to go) but noticeable if you carefully look?

[linx5o]

@BioCam

No, I believe you are referring to what some people call plate_holder "lips"
"Sloped" refers to the fact that the top surface is higher on the right than on the left, usually by ~2 mm.

I see. Thank you for clarifying. I'm not particularly familiar with these naming schemes. I will double check this also.

I don't understand what you mean by this. Could you please elaborate?

I have change the size of the x axis in the definition:
return PlateHolder( name=name, size_x=134.0, size_y=94.0, size_z=216 - 18.195 - 100,

Have not tested yet.

With regards to iSwap. I only have these modules defined. I don't have any generic plate holder. So any movements with iSwap wouldn't really show the effects of incorrect dimensions. They move fine between two instances of this module. I do need to use the pickup from top parameter to have it pickup lower down from the top. (May be due to my gripper module. The height seems correct but the module is two pointy pins on each side and when gripping to close to the top the plate just slides down.)

I will try to do some more tests.

[BioCam]

return PlateHolder( name=name, size_x=134.0, size_y=94.0, size_z=216 - 18.195 - 100,

I see, so you didn't change the child_location but instead changed the PlateHolder's size_x=135.0 -> size_x=134.0

I recommend you not do that:
The carrier you are using is MFX_CAR_L5_base which has a size_x=135.0 mm, which is...

1. the VENUS "ground truth"
2. confirms the fact that this carrier (like most carriers) is 6T i.e. "6 tracks"; each track has a confirmed size_x=22.5 -> 6 tracks * 22.5 mm/track = 135

Almost all MFX modules have the same size_x & size_y (based on their need to use the screw holes available for its fixtures.
Most MFX modules are completely flush with the base MFX carrier on each side of x.
Therefore, the MFX modules' size_x is the same as the MFX carrier's size_x =135mm.

If you use 134 mm you will see that the MFX Module doesn't sit flush on the carrier when using PLR's Visualizer.

But, tbf... the MFX Module's size_x doesn't actually matter - we are only discussing it here because PLR aims to model physical reality as accurately and consistent as possible.

Why does it not matter?

Because PLR uses a front-left-bottom (flb) parent-child relationship.
This means removing 1 mm of the MFX module size_x removes it from the right, which has no influence on the model's functionality.

---

What does matter a lot is the child_location, for which VENUS says you should be using...

def Hamilton_MFXmodule_tall_flat(name: str) -> PlateHolder:
  """Hamilton cat. no.: 188228
  Module to position a short / 'MTP' wellplate, i.e. wellplate size_z < 39 mm before
  breaching minimal safety height of 245 mm.
  Taller MFX module version of MFX_DWP_module_flat.
  """

  # Resource size is carried over from MFX_DWP_module_flat.
  # Child location offset for x, y are measured with caliper.

  return PlateHolder(
    name=name,
    size_x=135.0,
    size_y=94.0,
    size_z=216 - 18.195 - 100,  # Did you measure this using clld probing?
    # probe height - carrier_height - deck_height
    child_location=Coordinate(4.0, 3.5, 206.0 - 18.195 - 100), <== CHANGES MADE HERE
    pedestal_size_z=0,
  )

[linx5o]

I see. I measure the height of the lips and pedestal with clld probing. For x, y offsets. I measured the tabs with a caliper.

[BioCam]

Hi @linx5o, just checking in whether you have been able to verify the above plate_holder / "MFX Module" definition so we can update/merge this PR? :)

[linx5o]

@BioCam Sorry, I have not been able to verify. I have had some other things to work on. Will try to find more info on it soon.