TroughCarrier Integration

[BioCam]

Hi everyone,

In this little PR I am adding...

• the first instance of TroughCarrier, specifically Trough_CAR_4R200_A00 (Hamilton cat. no.: 185436)
• the first Hamilton-manufactured trough, specifically Hamilton_1_trough_200ml_Vb (Hamilton cat. no.: 56695-02), which fits into the above TroughCarrier
• created volume & height calculation functions for this trough (due to the non-uniform geometry I empirically measured a set of liquid volumes heights using PLR's STAR CMM function, and chose a polynomial fit to create these functions)

Next Steps

The functions achieve the following prediction accuracies:

# Calculation accuracy data:
# input_volumes = [6_000,  10_000, 20_000, 50_000, 100_000, 150_000, 200_000,
# 240_000, 300_000] in ul
# measured_heights = [5.8, 7.4, 10.1, 18.5, 32.9, 47.8, 61.7,
# 72.6, 88.4] in mm
# calculated_heights = [6.032, 7.163, 10.002, 18.597, 33.073, 47.529, 61.722,
# 72.726, 88.356] in mm

People might want to generate something more precise.

Troughs were previously just a Container. However this does not account for the true_dz and material_z_thickness of the through, i.e. the machine thinks the bottom of the trough is further down in z than it actually is, and when sent to the "bottom" will crash into the trough material itself.

Interestingly, this Trough_CAR_4R200_A00 actually has small oval-shaped pedestals that mean that the "trough_well"(?) directly sits on the pedestal, i.e. the inside of the trough is only off by the material_z_thickness=1.5 mm.

I temporarily added these 1.5 mm to the CarrierSites of the TroughCarrier to compensate for this problem.
This is not the cleanest solution.
However, there only appear to be 2 troughs for this specific carrier and it seemed better to push this definition out into the open-source community than try to solve this niche problem instantly.

Happy automation 🦾

[rickwierenga]

what is true_dz?

[BioCam]

The distance between the bottom of a plate/trough and the lower side of the well_material/trough_well_material.

I didn't want to name it dz yet because we haven't fixed dz in Plate yet.

But this information is needed if someone wanted to use this trough anywhere that is not a TroughCarrierSite with a pedestal. It is the same situation as with PlateCarrierSite.

[rickwierenga]

dz in plate is just a parameter that will determine the .location.z of wells.

I think since you're building this from scratch now, we might as well do it right from the start, I don't see a reason to sync up with plate. I hope true is something we should not have to use, because that implies there is a false somewhere. Probably that's true right now, but not something we should bake into the library like that.

Perhaps through_base_to_container_base or something could work?

[BioCam]

dz in plate is just a parameter that will determine the .location.z of wells.

As we discussed in PLR Carrier z-Height Issue this is an error, resulting from the incorrect VENUS-to-PLR transfer of ThicknessOfContainerBase to dz, which in VENUS is actually the distance between bottom/base of plate_skirt to outside_material_of_well_base).
I am confident that VENUS is not using plate_skirt_base_to_outside_bottom_of_well_base because it is too long, and instead simply called it dz in direct analogy to dx and dy.

I hope true is something we should not have to use, because that implies there is a false somewhere.

That is correct. The current well.dz is false as we know it is actually well.thickness_of_container_base / well.well_z_thickness.

But I see your point about immediately starting with the correct attribute names for troughs because we are starting from scratch with their definition and don't have to carefully adapt them like we currently have to do with Plate because Plate is used by every user.
So we can just rename this Trough.true_dz to Trough.dz and maybe make a comment to not confuse it with Plate.dz because Plate.dz has not been fixed yet?

[rickwierenga]

So dz is actually only a parameter of create_equally_spaced_2d. As with dx and dy, it is not an attribute of ItemizedResource (or Plate). In that method call, the name is self-explanatory.

I think for the attribute here, it should really be named something descriptive like through_base_to_container_base.

[BioCam]

As you mentioned though, for wells, we should be taking into account the well bottom material thickness. I see that as roughly analogous to through_base_to_container_base.

That is incorrect here: I've quickly made some rough drawings to visualise what the trough actually looks like:

I highlighted the Trough.through_base_to_container_base with the actual measurement I took for it, 1.2 mm.

Since the "TroughCarrierSite".pedestal_z_height = 1.5 mm, the trough will therefore sit with its container.base directly on top of the "TroughCarrierSite".pedestal, while the "Trough.skirt" is hanging in the air leaving a 0.3 mm gap below it.

This is exactly like a plate with just one well.

[rickwierenga]

This is actually not different from what I thought 😅 What exactly is wrong here? Do you want to update this PR? I can revert so you can update, then I can remerge.

I realize my original phasing was not clear. This is not analogous in the physical geometry of these resources. I was just saying these are properties of "single-class" Resources and cannot be modeled as relations between resources. The well-dz is modeled as the relation between resources (namely in Well.location).

[BioCam]

Because a Trough has no child (or parent), we have to define the through_base_to_container_base as a separate attribute. The alternative would be a "trough-parent and trough-child"-like structure, where the trough-child (the actual Container) is raised wrt trough-parent.

Yes, this is becoming confusing. Because a container is currently essentially a "paperbox", i.e. an object with no material_thickness associated with itself, i.e. all walls are believed to be 0mm wide, if I understand this correctly.

This is fine for wells because they sit inside the bigger plate - with the notable exception of their z-height, which is part of the big problem with Plate that we are trying to fix atm.
But in the case of troughs this does not really work as you can see above, because not only do we need to account for the material_thickness (at least in z) but here we also have to account for the "trough.child" / "container inside the trough" to be located at an offset to the left-front-bottom / origin of the trough.

[BioCam]

Do you want to update this PR? I can revert so you can update, then I can remerge.

I realize my original phasing was not clear. This is not analogous in the physical geometry of these resources.

No, I think we can leave this definition for now because I updated Trough to include

• material_z_thickness=1.5 &
• through_base_to_container_base = 1.2,

-> With this information people can aspirate/dispense with offsets = [Coordiante(x, y, through_base_to_container_base + material_z_thickness] which will then correctly target the bottom of this trough.

If we find this is cumbersome we can figure out a neater way in the future.

[rickwierenga]

I think in lh.aspirate or even STAR.aspirate & co we can incorporate this. Specifying offsets for every operation is not neat, that is something we can easily do automatically.

[BioCam]

I just realised I forgot to include volume=0 / height=0 in the polyfit.

Here is the updated accuracy data:

Ohh, I forgot to mention: this trough says it is for 200ml but it can actually fit a bit over 300 ml :)