Picking up sketchy off-brand tips

[rickwierenga]

original thread: https://discuss.pylabrobot.org/t/liquid-handler-auto-detection-of-real-tip-presence starting new thread per cam’s suggestion, keep things organized

@harley

knowing if tips are picked up/present when I have used off-brand or generic tips instead of the Hamilton ones.

this could be fixed with more accurate tip definitions, it’s easy to make them yourself (if you know the exact dimensions and if the tips are manufactured consistently)

(just a thought, let’s discuss this topic further in this thread)

cc @ben

[ben]

We have 1.6 million these “sante” sketchy off-brand tips.

These are precisely like hamilton tips, so they don’t cause errors most of the time. However, the tip tray physically sits 1mm below the normal hamilton tip tray. Very rarely, the STAR will refuse to pick up the tip because it detects the tip collar height is incorrect

I was able to resolve this error with a more precise tip definition 1mm lower.

[harley]

For me, it goes back to this post where I was seeing issues using these 50uL tips on a STARlet.

@harley

Looking around some more and asking our mutual friends at Nugget: looks like the 50uL tip crunching issue is specific to the generic tips I bought. They are slightly longer and narrower than the Hamilton tips. I bought some Hamilton tips to test so we’ll see if its the tips or the robot causing the issue.

I would also have issues picking them up sometimes, where it would give a channel error. I need to go back and track down the error (switching tips was the solution) but essentially it would pick up the tip, give an error that the tip was not picked up, then proceed with the aspirate/dispense instructions but not actually transfer any liquid.

[CamilloMoschner]

Hi @harley,

I’ve asked our Hamilton contact who answered a question I had in regards to your query:
“How do Hamilton channels know they have picked up a tip?”

Hamilton explained the presence of a tip is evaluated via a sensor in the channel that measures the retraction of the channel sleeve!
(for some reason I imagined some form of pressure- or direct piezo-sensor in the channel bottom)

I believe this can explain the issue you have seen:
The sensor would require the sleeve to be (perfectly) pushed upwards by the tip that it picks up.

There are now a couple of things that can go wrong with knock-off tips:

1. knock-offs might not have the exact same TipRack + Tip dimensions - both have to be right! → if it is just a z-dimension issue (in either or both) then one could just modify the definition; this might have been the case with @ben’s tips (mentioned above)
2. But if the Tip’s fiting_depth or collar or even the straightness of the tip top isn’t correct (e.g. you could imagine an incline in the top) → then the sleeve might not be perfectly pushed up.
3. The groove into which the O-ring expands to (CORE_I tech) / the metal bearing expand into (funnily still named CORE_II tech) could be mispositioned or have the wrong dimensions & tolerances → the tip could theoretically be recognised but might not be picked up
4. Everything might be correct … for most tips; but the knock-off manufacturer’s quality control might be crap, i.e. there is higher variability in any or all of the tip’s dimension → this could lead to occasional tip_pickup failure.

What I believe you might have encountered:
Option 2 (some issue with the Tip pushing sleeve up) combined with proper engagement of the squeezer driver combined with sloppy manufacturing QC
→ in this situation, occasionally, the squeezer drive might have correctly engaged with your tip, leading to a pickup, but an issue with the Tip dimension itself leads to a failure of the sleeve being pushed up, in turn, leading to a failure to be recognized as a tip pickup.

If the system (I’m actually not sure whether it would be the firmware itself or PLR, if you just brushed aside the error and continued likely PLR) doesn’t know that you have a tip a on the channel, it will not allow you to perform an aspiration.

The good news: This is not a PyLabRobot issue, it is a tip compatibility issue with the hardware

I’m curious: Have you tried out these exact tips in VENUS - to a throughput equivalent to PLR to see the occasional issue - and were they picked up correctly consistently?
Whether I’m talking (at least partial) nonsense here depends on VENUS having the same issue, i.e. “failure to recognize tip_pickup, when tip_pickup has occured”
(In terms of firmware - the only thing that matters in the end - there is no difference between PLR and VENUS)

I believe this is a different issue though to the one you hyperlinked to:
“crushing of 50ul tips during discard” - which actually was a difference in the tip_length of other knock-off tips?
(which can easily be fixed with a new PLR HamiltonTip defintion, i.e. one with longer tip_length)

Or are these the same knock-off tips but with 2 different issues?

[harley]

@CamilloMoschner

Or are these the same knock-off tips but with 2 different issues?

Yes that was the case - same 2 issues with the same tips. I never actually tested it with VENUS but I also believe it is a hardware issue that would be corrected by giving it more specific location parameters for fitting the tips AND having higher quality control on tips for consistency.