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 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?
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:
In your case, the end goal would be to:
Auto ‘Cancel’ channels which throw the error code of interest
In an error handler, parse the step data of each channel to determine which (if any) channels were affected
For parsed channels, generate a channel pattern and custom sequence corresponding only to the affected channels and wells respectively
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.