Dispense error handling/recovery

[galen.w.miller]

Hello All,

I have a method that watches for clots on the aspiration and records them for the user to manually transfer as needed. The aspiration side works well, but when the sample goes to dispense it throws an error about not having enough liquid (this is also expected). The problem occurs when we push the “Available” button. Instead of going into the well of the DWP to dispense (the default dispense height for samples that don’t error is 10 mm from the bottom) the tip will hover over the top of the well and dispense. This results in bubbles and possible cross-contamination across the plate.

I would like to transfer whatever volume was aspirated, but into the bottom of the well. Does anyone know of a fix for this issue?

Thanks in advance,
Galen

[galen.w.miller]

Error for reference. The text reads:
“Not enough liquid;
Available are '300.0’ul required are '300.0’ul.”

[dominik.b]

I believe you could change the dispense mode to empty tips, then everything that is available will be dispensed.

[galen.w.miller]

Thanks Dominik!
That should work for the actual pipetting (which is the most important part). Can you think of any way to still note the wells as errors/failures and pipet to the bottom as a part of the error handling?

[NickHealy_Hamilton]

Hi @galen.w.miller

To track, handle and specify custom actions for specific channels/wells that were affected in a particular ML_STAR step, you will want to use a combination of custom error handling by user and the step return data returned from your aspiration step in question.

There are a couple thorough examples already on the forum that I strongly suggest reviewing, as this will guide you to be able to get exactly the level of control you are looking for for this type of scenario:

Increase Channel Height during cLLD error

Hi @ninjasquad31 and welcome to the forum! Custom error handling will be required to overcome this issue but as @bowlineknot mentioned, you can parse the return data from the aspiration step to set additional recoveries custom to the needs of each channel based on whether or not it encountered an error. Brief step data overview: Step return data can be used or a number of different ML_STAR steps and capture a ton of useful tracking data for each sample/channel combination of an aspiration ste…

Handling Clot Errors

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: [image] 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. [image] [image] Within the logic that sets the recovery based on error code, you can a…

In your case, the end goal would be to:

1. Auto ‘Cancel’ channels which throw the error code of interest
2. In an error handler, parse the step data of each channel to determine which (if any) channels were affected
3. For parsed channels, generate a channel pattern and custom sequence corresponding only to the affected channels and wells respectively
4. Use the custom sequence and channel pattern to use an additional aspirate step in the error handler, but this time using ‘bottom’ and ‘available’ step parameters

The linked posts break down this very useful technique in granular detail, highlighting two different use cases.

Hope this helps. Thanks.

-Nick