I am building a plate normalization protocol that uses PLLD liquid level sensing when aspirating from the source plate. We have a problem when any of the channels encounter in Improper aspiration error, the bottom recovery does not work. So, instead of aspirating from the bottom, it throws off another improper aspiration error.
No matter how many times we repeat this, the only way to continue the message without avoiding it is to exclude those channels. However, this leads to the destination sequence not being modified accordingly for the skipped source position, leading to improper transfer sequence.
This error appears when there is not enough liquid or there’s no liquid in the wells but, for those cases, we just want to aspirate from the bottom just to be sure. Also CLLD doesn’t resolve this either.
I believe the next step is to use a customized error handling step, but I do not know if that would work if the default error handling does not work either.
Unless the Aspirate step’s default Error Settings have been modified, the following recovery options should be available during an Improper Aspiration error (image does not include the ‘Cancel’ option which is also available by default):
As you noted, the Improper Aspiration error occurs when there isn’t enough liquid in the wells, but this requires the MAD (Monitored Air Displacement) functionality be enabled to trigger. This functionality is not turned off when using the ‘Bottom’ recovery, so if the well volume is low/empty then an Improper Aspiration error will occur again. Following the first repeat of this error, the ‘Continue’ error recovery can be used to Dispense the liquid to the proper locations.
If you’d prefer to use the ‘Bottom’ functionality in the way you describe, then you would need to setup customized error handling to ‘Cancel’ out of this Aspirate step and either loop back with different settings or move onto a different Aspirate command.
All that said, based on the information so far it sounds like the wells being low/empty is expected. As such, I would suggest using the ‘Aspirate all’ Aspiration Mode:
This mode turns off liquid level calculations and MAD, effectively skipping the Insufficient Liquid Level and Improper Aspiration errors (Liquid Level errors would still need to be handled using ‘Bottom’ recovery). This mode is used exactly for this situation in which low/empty wells can occur, but drawing the entirety of the remaining volume is the goal.
Thank you @DanHartman_Hamilton for the explanation! If the channels were to encounter an insufficient liquid error or liquid level error, is the MAD functionality turned off when using the Bottom recovery? Or will I also get an improper aspiration error instead?
Only one Error Recovery option will turn off MAD, which is the ‘Available’ recovery. This option is available by default for Insufficient Liquid Level errors, but not Liquid Level errors.
The purpose of ‘Bottom’ is to repeat the Aspiration steps with the exact settings as specified in the method (including MAD), except that it occurs at a Fixed Height of 0mm.
In that case, I will go with the customized error handling step to aspirate from the bottom (fixed) if any of those three errors occurs. If I run into any specific problems doing so then I will come back to this thread for additional help.
Apologies if this got lost in my explanation, but if you use the ‘Aspirate all’ Aspiration Mode, then you won’t need customized error handling.
With ‘Aspirate all’, both the Insufficient Liquid Level and Improper Aspiration errors won’t occur. In the case of a Liquid Level error, using ‘Bottom’ recovery won’t receive an Improper Aspiration error because MAD is turned off by the ‘Aspirate all’ mode.
Oh thank you for the clarification on that as it does provide useful insights! While that will be ideal, I spoke with my colleagues who will be using this protocol and they want to keep records of wells that had little-no liquid in it. After all, it is difficult to spot empty wells in a plate full of non-empty wells, especially when the labware and liquid is transparent
In order to keep record, the error needs to occur to extract the specific positions of those empty wells. Otherwise, if I bypass using the Aspirate All aspiration mode, then the robot will not know if those wells did encounter such errors to record in our mapping file?
That is correct regarding the mapping file. As such, I will offer one further solution. By adding the ‘ML_STARLib’ library (a default library) to your method, you can use the ‘AspirationMonitoring_On/Off’ functions to toggle MAD on and off at given points in your method. This is useful when only specific blocks of pipetting steps need MAD on/off:
