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 step (barcode data, labware ID, position ID, high level controller error code, low level module error code etc). This can be used to rebuild channel patterns and sequences from select groupings of channels and influence recovery behavior specific to a type of error (or lack thereof).
See from the VENUS help documentation further explanation of step return data as they apply to 1mL channel steps:
Example of step data from a tip pickup step which had channels whose errors were automatically handled:
Error recovery buttons:
In the following example, instead of parsing for the specific high level or channel error code for insufficient liquid level, I bound automatic error recoveries to ‘Cancel’ for either instance where a channel could not detect sufficient (or any) liquid for the aspiration.
In the step data for any affected channels, there will be a value for the error recovery button that represents Cancel (2). The major recovery button values are enumerated by the ASWGlobal library, which is what I use for such purposes. Channels that executed without error will have a value of 0 for this field of step data. Note that without the use of automatic error handling, an unhandled cancel will abort the run.
To see an alternative example that parses for high level error, see the following post:
https://forums.pylabrobot.org/t/handling-clot-errors/2444/8?u=nickhealy_hamilton
Programming example summary:
This is considered an ‘advanced’ VENUS programming concept, but I have prepared an example that accomplishes this in a minimal amount of lines. Note that there are several ways to approach this, and this just demonstrates one technique. This requires use of the HSLMlStarStepReturnLib and and HSLErrLib libraries, which both install with VENUS. Because this is an ‘advanced’ example, I am not going to break down every line of code in this post, but am happy to answer any follow up questions.
Essentially, aspiration steps are placed in a while loop. On the first attempt, all channels will be activated via the channel pattern variable. On instances where one or mor channels incur either an insufficient liquid or no liquid error (see above) then the step will be cancelled and jump to a custom error handler (after the unaffected channels finish their aspiration).
Upon entering the error handler, (if necessary) step data is recovered from the cancelled aspiration step from the currently active error object, and a ML_STAR command is used to move the channels to max height. Finally, the recovered step data is parsed by a function to flag any channels that were cancelled, and rebuild a new channel pattern of channels that need to be repeated. This new channel pattern overwrites the old one, and the aspiration is repeated until the step completes without error.
Because I am only rebuilding a channel pattern for each repeated step, and not a new sequence, for the reused aspiration step I have sequence processing set to ‘manual’ and channel usage set to ‘channel pattern’, so that when the aspiration step is reused/repeated, the deactivated channels which have already properly aspirated (and their corresponding sequence positions) will be properly ignored by the step:
The aspiration sequence is not modified until an aspiration step occurs without error.
Programming example code:
Pipetting function (no parameters in this example):
Step data parsing function with parameters:
Hope this helps! Let me know if there are further questions.