Revising TipRacks

[CamilloMoschner]

@CamilloMoschner

@cwehrhan

FYI there’s these tips too, used in clean room rooms and hyper sterile environments:

https://www.hamiltoncompany.com/consumables-labware-accessories/co-re-and-co-re-ii-tips/tip-boxes

Thank you for sharing @cwehrhan - they look like a colored TipHolder with the standard EmbeddedTipRack on it?

This is very nice!

@cwehrhan, do you know whether the process of removing the lid for the tip rack is automatable?

[CamilloMoschner]

I don’t think modelling the TipSpot to refer to the bottom of the tip_rack holes is universally logical:

• for EmbeddedTipRacks the hole_size_z gives the tz/za location but for StandingTipRacks the hole_size_z does not
• TipSpot is a “spot” by name, i.e. a 2D object (?)
• I am not aware of a use case for the explicit recording of the hole_size_z by itself (?)

If TipSpot were to be defined by the top of the hole opening it would…

1. be universally applicable to all tipracks,
2. always be defined with its own dx, dy, and dz location relative to the tip rack itself,
3. instantly provide the machine-required tz/za information and
4. would be easily measure-able by the machine (in this case STAR) itself via ztouch probing.

Note: I added a model for the hamilton_96_embeddedtiprack_raised (?) which Hamilton seems to call 96-Well Tip Adapter (even though a well, by definition, has a bottom and this tip rack has only holes) as an example of another Hamilton EmbeddedTipRack.

[adamferguson]

I checked out the labware definitions for the tips in Venus, and it turns out the collar height is defined as “segment 1” for the tip container definition (10mm for the 1000s (pic below), 8mm for the 300s and the 50s).

For what it’s worth, Venus defines the tip z location by the distance from the bottom edge of the rack (the surface that rests on the tip carrier) to the end of the tip (they call this dimension “distance from base of rack to outer base of all containers”, normally this would be the Z distance between a plate skirt and the bottom of a well).

Just thought I would put some additional info here, some of this may be obvious but just in case it’s not:

• There are two versions of the 96-well tip adapter: one for CORE 1 heads and one for CORE 2 heads – they have slightly different geometry. It would make sense to specify which one you’re using to avoid confusion in the future (the CORE 2 one has “CORE 2” engraved into it) Not sure if CORE 2 is supported in PLR yet? There is a firmware update for instruments that have the CORE 2 tip attachment mechanism.
• What you guys are calling “embedded tip racks” have historically been referred to as FTRs (officially “framed tip rack” from Hamilton, sometimes we used to call them “floating tip racks”. Just an FYI, don’t necessarily think there’s anything wrong with calling it embedded.
• I’ve never seen Hamilton Standard/Framed/Embedded tip racks nested into each other, only NTRs and stacked tip boxes. Physically, they do actually nest ok, but there is a lot of XY play in the location when doing so. Picking these racks up and placing them into a nest with the CORE grips or iSWAP doesn’t work very well – hard to squeeze the tabs that hold them into tip nests. You would also run into traverse-height limits quickly with the 1000uL tips.

I’m curious if anyone has used nested tip racks in PLR yet? I see there is an NTR carrier definition in resources.

[rickwierenga]

@adamferguson

• There are two versions of the 96-well tip adapter: one for CORE 1 heads and one for CORE 2 heads – they have slightly different geometry. It would make sense to specify which one you’re using to avoid confusion in the future (the CORE 2 one has “CORE 2” engraved into it) Not sure if CORE 2 is supported in PLR yet? There is a firmware update for instruments that have the CORE 2 tip attachment mechanism.

are the sizes actually different? so far we have only been using one definition and it seems fine? if they are different we would need two definitions. the current definitions are definitely based on core-i (core-ii wasn’t released yet when I made them…)

[adamferguson]

Ya they are different – the CORE 2 one is thicker. I believe this is because the CORE 2 mandrels/stop disks are longer (they seat more deeply into the tips), so the adapter needs to be taller to prevent them from hitting something next to it during an offset tip pickup.

[cwehrhan]

@CamilloMoschner

@cwehrhan, do you know whether the process of removing the lid for the tip rack is automatable?

Yes you can, I think iswap would work but have mostly done it with the CORE grips.

Also they use the same inner plastic holder as regular embedded tip racks.

[cwehrhan]

I can’t find it right now but Artel ran a study that showed the Hamilton 96heads have “edge” effects when picking up tips. Hamilton added the two middle pins to the tip racks after that. Still if you’re looking for the highest precision dispense its best to pickup from these…. we rarely do though. Just wanted to point this out that they aren’t just used for sorting. I did find this poster from artel, but I swear there’s a real study/poster. Might be off topic lol

[CamilloMoschner]

@adamferguson

10mm for the 1000s (pic below), 8mm for the 300s and the 50s

and 6 mm for the 10 uL tips?

@adamferguson

For what it’s worth, Venus defines the tip z location by the distance from the bottom edge of the rack (the surface that rests on the tip carrier) to the end of the tip (they call this dimension “distance from base of rack to outer base of all containers”

Yes, isn’t this why the TipRacks are “hardcoded” to a specific tip type in VENUS?

@adamferguson

Not sure if CORE 2 is supported in PLR yet? There is a firmware update for instruments that have the CORE 2 tip attachment mechanism.

Absolutely - I have actually only ever used CO-RE II (which should rather be called “Metal Bearing Expansion” Technology imo because there is no O-Ring Expanding anywhere anymore [to my knowledge] ).

To my understanding, the firmware update actually takes care of all the updates?
At least I never had any (noticeable) issues with CO-RE II tips.

@adamferguson

Thank you @adamferguson !!
This is some very important and actionable information. It makes a lot of sense to raise this embedded tip rack higher considering the longer “CO-RE II” head bottoms!
But I did not know about it and you might have just saved my 96-head from an uncomfortable encounter with a tip carrier during the planned (but not yet PLR-possible) partial tiprack pickup
I’ll make sure to use the correct, taller hamilton_96_embeddedtiprack_raised_core2.

@cwehrhan

Hamilton 96heads have “edge” effects when picking up tips. Hamilton added the two middle pins to the tip racks after that.

You mean that tips on the periphery might not be…
(1) picked up properly (e.g. the center of the tiprack bends downwards under the pressured of the 96-head and therefore the tips on the periphery would tilt inwards?), or
(2) might have incomplete sealing of the old expanded (black rubber) O-ring or new lowered (red rubber) O-ring, leading to air-creep into the piston and resulting failure of aspiration/dispensation accuracy?

And that a totally flat sturdy surface like the hamilton_96_embeddedtiprack_raised_core1/2 is the way to ensure this cannot happen?

[cwehrhan]

@CamilloMoschner

You mean that tips on the periphery might not be…
(1) picked up properly (e.g. the center of the tiprack bends downwards under the pressured of the 96-head and therefore the tips on the periphery would tilt inwards?), or
(2) might have incomplete sealing of the old expanded (black rubber) O-ring or new lowered (red rubber) O-ring, leading to air-creep into the piston and resulting failure of aspiration/dispensation accuracy?

And that a totally flat sturdy surface like the hamilton_96_embeddedtiprack_raised_core1/2 is the way to ensure this cannot happen?

It was 100% present with CORE1 and tip rack adapters that did not have the two metal pins. It was still somewhat present with the metal pin supports. I believe it was O-ring not sealing all the way as the middle of the rack bent so much… though this was discovered before my time and the two pin tip racks were already implemented. I swear there’s an artel poster for it but can’t find it anywhere. I believe it was very very small amount, but still no one was measuring heat maps of plates until artel and they found this error.

I have no idea if this is replicable with CORE2….

It’s more of the rigid surface.

[cwehrhan]

Bowed decks too…:Checking Dispensing Volume - #21 by DanielYip - liquid-handling - Lab Automation Forums

^ I wouldn’t be surprised if this was a missed diagnosis of the rack bending tbh

[adamferguson]

@CamilloMoschner

and 6 mm for the 10 uL tips?

Yes looks like 6mm for the 10uL tips (don’t have physical ones to confirm though)

@CamilloMoschner

To my understanding, the firmware update actually takes care of all the updates?
At least I never had any (noticeable) issues with CO-RE II tips.

Great – one less thing to worry about .

[rickwierenga]

@CamilloMoschner

I generally agree that not all StandingTipRacks have to be able to be nestable… but I cannot think of an immediate example that cannot - Opentrons ones can:

Opentrons racks stand by themselves, but the top part still looks like an EmbeddedTipRack to me, and the bottom could be a “TipHolder” as you call it. In that picture.

The Hamilton NTRs are clearly StandingTipRacks though.

This is an Opentrons specific question, I can get started with other work before making this decision.

@CamilloMoschner

• I am not aware of a use case for the explicit recording of the hole_size_z by itself (?)

we would still need to know the size z of the EmbeddedTipRack, and where the hole is wrt the EmbeddedTipRack lfb. While the hole does not necessarily “need” a size, we would still be measuring this length of information if we defined TipSpots as “the top surface”. Either the TipSpot will be at location z=Z or at location z=0 with size_z=Z.

In the case of StandingTipRack, I agree it’s more difficult to measure and kind of pointless.

I am inclined to agree with you for this reason, making them flat surfaces makes sense so it’s consistent between ETR and STR.

[rickwierenga]

it’s not just re-modeling, we actually need to figure out what the measurement of all of these things are.

in the labware editor (per @adamferguson’s suggestion) the tip sections are:

• 6 + 24 = 30mm (10uL)
• 8 + 52 = 60mm (300uL)
• 10 + 85 = 95mm (1000uL)

meanwhile the firmware commands (and thus PLR) defined these lengths as

• 29.9mm for the 10uL tips
• 59.9mm for the 300uL tips
• 95.1mm for the 1000uL tips

I wonder why and where this comes from.

in my calipering the 10uL and 1000uL tips are 29.9mm and 95.0mm long.

the differences in collar height do explain this hack which has been in PLR since the beginning:

    # not sure why this is necessary, but it is according to log files and experiments
    if self._get_hamilton_tip([op.resource for op in ops]).tip_size == TipSize.LOW_VOLUME:
      max_tip_length += 2
    elif self._get_hamilton_tip([op.resource for op in ops]).tip_size != TipSize.STANDARD_VOLUME:
      max_tip_length -= 2

(at first I was a trying to match the firmware command values based on what I saw venus generates + numbers I saw in venus [instead of thinking about physical reality], but at that time I didnt know about the labware editor.)

[rickwierenga]

is anyone using NestedTipRack Create NestedTipRack Class by BioCam · Pull Request #228 · PyLabRobot/pylabrobot · GitHub?

[CamilloMoschner]

Yes I am - quite cumbersome atm though and very eager to build properly

[rickwierenga]

@cody what tip carrier are you using on the nimbus? I am updating the tip spot model and want to make sure the nimbus is updated correctly. in the tests I was assigning a tip rack to the deck directly which is not physically possible

[rickwierenga]

@cody also I am finding I need a strange tip_offset to match the values of begin and end-pickup to what is on main currently. I think the model in main might be incorrect, but I didnt want to change the behavior compared to the version you pushed given I am not able to verify these things myself. if you have time, could you please verify what venus does for non-1000ul tips on the nimbus? and if possible, maybe test my code with tip_offset=0 for all tips?

Update Nimbus backend to use EmbeddedTipRack model

[Cody]

Hey! Yeah, happy to test. The Nimbus models compatible with sliding carriers use 4 SBS position carriers compared to the 5 positions typical on STAR/STARlet. I’m using one with 3 FTR tip sites, last site is 6 x 50mL vertical reservoirs. Not currently defined in main. Happy to run your changes to see if there’s any problems.

[Cody]

@rickwierenga

need a strange tip_offset to match the values of begin and end-pickup to what is on main currently. I think the model in main might be incorrect

The model in the notebook, or somewhere else?

[rickwierenga]

amazing!

@Cody

The Nimbus models compatible with sliding carriers use 4 SBS position carriers compared to the 5 positions typical on STAR/STARlet. I’m using one with 3 FTR tip sites, last site is 6 x 50mL vertical reservoirs.

I see, thanks. (if you ever wanted to contribute them that would be welcome :))

for now in the nimbus unit tests I just updated the tip rack to sit 6.1mm lower as the new model requires (the sinking depth of the “EmbeddedTipRackHolder”, as it’s called for now.)

The model in the notebook, or somewhere else?

In the linked commit in that branch. It’s not in main yet because I still working on it.

I added tests for 10, 50, 300 and 1000ul tips based on what is currently in main and aiming to make that branch not change these values. However, I am not sure if main is currently correct.

So we will need to figure out two things:

1. does main work? ie are the tests there correct?
2. with the new model, tip pickup/drop is 0.3mm higher for 50uL tips and 0.2mm lower for 10 and 1000uL tips. This could be the result of them being modeled incorrectly in venus (I want to say this is most likely), or something wrong with my measurement of their “collar height” (the part of the tip sticking out above the tip rack, that it hangs on). I wonder if these values work (better)