Hamilton Tip Detection

Hamilton (Venus)
1

Is there a way for Hamilton to detect in Venus when the 96 head did or did not properly pick up tips?

Thanks!

2

As far as I know, not without some sort of complex workaround. But if you use liquid level detection, it has the effect of checking if tips are present, as otherwise the liquid is not detected. This will not work with the clear tips.

3

Hi @trand16,

Both the base multiprobe head (MPH) and the TADM MPH do not have the ability to detect tips being picked up. Both models do have cLLD channels for A1, B2, G11, and H12 and this can be seen from their slightly different color to the rest of the channels (beige versus silver). But the TADM MPH has pressure sensors on each of the 96 channels and so during an aspirate step that occurs post tip pickup you can use TADM to determine if tips were or were not correctly picked up.

Otherwise, as @Evolucian said, you would likely need a complex workaround. For example, use filtered tips and a camera channel (which you may or may not have on your system) with a modified program from one of our easyARW workstations to take a picture of the tip rack where you just picked tips up from.

This being said, would you happen to be asking about this because you have an MPH that is failing to reliably pick up tips?

Matt

4

Hey thanks for the message. @MatthewSmith_Hamilton . No I am developing a script that picks up tips multiple times in a run with the 96 head. My concern was that a tech forgets to reload tips and then my script doesn’t allow them to pick up tips again. But I ended up just scripting in to prompt them when to reload tips.

Thank you!!

5

Hi, you can also make the 8 channels to take/drop tips, to be sure the tips were added

6

Does the Hamilton 96head have a separate pressure sensor for each channel? This is amazing!

7

Hi @Yang, only on the TADM MPH model. Most MPHs in the field are non-TADM models but they can easily be identified by having an additional e-chain as seen in the image below:

image
image376Ă—379 52.7 KB

1 Like
8

That’s great, thanks for your response.

1 Like
9

Thanks yall

10

@MatthewSmith_Hamilton, I am revisiting this thread to gain a deeper technical understanding of the underlying hardware logic for the CO-RE 96-Multi-Channel Head, specifically regarding Z-axis feedback and tip sensing.

There are a few technical areas I am hoping to clarify:

1. Z-Drive Feedback and Collision Detection
The Z-motion profile of the 96-head is distinct from the independent 1 mL channels. I have noted that the Z-drive does not typically report “Step Loss” in the same manner as the independent channels. Is there a mechanical or firmware-level reason why Z-plane crash detection/step-loss monitoring is handled differently on the 96-head assembly?

2. Tip Presence Logic on XRP Channels
It is my understanding that XRP channels primarily utilize Z-location step loss to verify tip presence (e.g., descending past the expected pickup point triggers a “No Tip” error).

  • Is capacitive sensing (cLLD) bypassed for tip verification because the delta in capacitance before and after pickup is too negligible to serve as a reliable logic gate?
  • Is there any way for a user to access the raw capacitive signal (or a pre/post-pickup value) via potentially firmware get commands to use as a supplemental “tip on vs. tip off” sanity check?

3. Workflow Optimization
Currently, to ensure tip existence, we perform a quick “pickup and place” sequence using the XRP channels. However, this adds significant overhead to our protocol timing during each tip reload. We are looking for a more efficient method to validate tip presence without this physical move, potentially through the aforementioned capacitive delta or even computer vision.

I would appreciate any insight into the raw sensor data available for the 96-head that might allow us to streamline this verification process, as both the typical and TADM have cLLD.

11

Hi @zachary.milot,

See below my responses to your inquiries:

  1. Z-Drive Feedback and Collision Detection:
    The Z drives of the independent channels and the multi-probe head are different. Most differences you notice can easily be summed up to the size differences between the two as well as the fact that channel z-drives are belt driven while the MPH is on a spindle. Notice that when the system is powered off you can easily move the channels up and down but the MPH has a ton of resistance. It just takes so much more force than channels to start/stop moving the MPH or have it stall, and increasing the sensitivity of the MPH’s Z drive is likely to only result in premature step losses. So while the MPH isn’t capable of replicating gentle Z stalls in a manner equivalent to the channels, improvements have been made to MPH firmware to get closer. It also isn’t to the point where we can rely on Z stalls for tip pickups using the MPH. Without this, we can’t monitor height as feedback, meaning the MPH can’t use tip type recognition.

  2. Tip Presence Logic on XRP Channels
    Tip pickups with channels are basically as follows:

    1. Channels move down in Z to the starting seek height (LLD seek height from .ctr definition).
    2. Channels move down in Z at lower speed until it either stalls in Z or reaches the end of the Z seek range (via .ctr dead volume height) which will always correspond to the bottom collar/frit Z position). If the Z stall occurs within the allowed seek range, the Z height of the stall is reported.
    3. The difference between the end of the stop disc (stall position) and stall shelf height is known and the stall shelf position relative to the bottom Z (end search range) is evaluated against its allowed error deviation range (+/- 1mm from target stall shelf height)
    4. If within the allowed range, firmware checks that the collar of the tip has forced the spring loaded eject sleeve into the recognition position (confirms stall was against a tip), the squeezer engages and the channel moves up in Z until the end of the tip is at traverse height (known from tip type definition values). If outside of range you get a no tip/wrong tip type error and the channel moves the stop disc back to traverse height without engaging the squeezer.
      So a tip pickup only utilizes position and expected step losses and is completely independent of cLLD.

  3. Workflow Optimization
    Unlike every independent channel, the MPH is only equipped with cLLD sensors on A1, B2, G11, and H12. And while also stating that the channels can utilize stall position as well as collar retract position to verify tip presence while the MPH cannot, I think that you will find that validating tip presence for the MPH by a mechanical means is quite difficult. In regards to channels though, instead of using a “pickup and place” method, have you considered just loading more tips than needed on the deck and utilizing the “next” option in custom error handling? If a channel fails to pick up a tip the next option will have the channel move to the next available position and try the pickup there.

1 Like