Handling Clot Errors

During our blood extraction method, we occasionally have samples that have clots during transfer from source tube to a deep well plate. The default error handling for clot errors is not desired. Is it possible to eject the tip that detected a clot, get a new tip and try aspirating from that same source tube again? If it is possible, how would I go about doing that?

Hi @Wes ,

Short answer is this can be handled using User Error Handling and setting the recovery to be Cancel. I have put together an example that should help explain the steps better that can be downloaded from the link below:

https://download.hamiltonsupport.com/wl/?id=RNr77f5XpZ7rdvaKF4POmJjxIo1aEE4J

The example method is configured such that you can specify the number of retries it will make before moving on.

I hope this helps!

3 Likes

I share another handling way that my colleague did, which I think was easier. Set default error handling of clot to exclude in aspirate step, then clotted sample will be excluded or skiped when dispensing, and all other samples will be transfered to right positions. With step of get channel exclude state in Miscellaneous, you can get pattern of exclude channels and step data of recovery details. Using the pattern, and the sequences for pipetting (without any modification), you can do other operation on the clotted samples after picking up new tips.

3 Likes

Hi @BrandonBare_Hamilton thank you for responding. I was able to download the example file, but I’m having trouble opening the method after importing the pkg file. I keep getting this vague error, screenshot below.

image

Hi @Wes ,

My apologies. It seems one of the libraries the method used was still in an older version of Venus that is causing that issue. Importing this pkg for the Channel Patterns Library and overwriting what you have on your computer will fix the issue. Easiest way to ensure it is updated is to delete the folder “C:\Program Files (x86)\HAMILTON\Library\Channel Pattern” prior to importing the pkg below.

https://download.hamiltonsupport.com/wl/?id=WVi4wfQoEDcBOc4ALyxloPTYHQ0Ed08j

2 Likes

Thank you @BrandonBare_Hamilton! I’ll have to test this out!

Hi @BrandonBare_Hamilton,

Similar to this error-handling, I’m looking for a way to handle insufficient liquid errors, based on this error first able to repeat the aspirate step (general error handling with changes submerge depth), followed by the ‘Exclude’ option, in such a way that the target sequence is still in place for the correct samples (currently, target sequence is not modified accordingly, leading to incorrect transfers). And as a bonus, mapping the non-transferred samples. Do you have a fix for this?

Kind regards

Hi @Kees ,

Using the same logic from the example method above, you can do some of these custom error handlings based on the error codes returned. See below a list of the Main Error codes that the logic would use:

For the submerge depth change, you would need to feed it into your aspiration step as an array of variables, so I would recommend setting the default values outside of the retry loop.


Within the logic that sets the recovery based on error code, you can add the if statement for the Insufficient Liquid level error. Within that logic you can set the submerge depth to the retry depth for that channel.

You can use a different error handling based on the retry counter. Cancel is what my example uses, but if the loop = the total retry then you could go down the exclude route.


Using the following codes for recovery, you can build your own output file for Excluded wells.

image

5 Likes

Works like a charm, thanks!

2 Likes