Hello all, I had a quick question. I have a MIDI plate on a CPAC position for a protocol. If I run into a cLLD error in the columns the channels are lifted to a certain height. Is there a way to increase that height without going through any custom error handling so that we can remove the plate to examine and put it back on?
1 Like
My guess is that you will need to use EHBTU and FW commands to get this to max Z so you can get the plate out.
Is this something that can be incorporated to happen throughout the method? The way I have it set up right now is using the custom error handling function. Within that first branch I have the aspirate step. If a cLLD error is detected, it’ll then go into the custom error handling where the channels are brought to zmax, a custom UI pops up and allows for the user to intervene, and once everything is fixed and the user acknowledges the prompt, it tries to aspirate again. The problem I’m having is during that first aspirate, if one channel is able to find liquid and the rest fail, then after the error handling during the second try of the aspirate step, since that first channel already has liquid in it, the method aborts. It tries to aspirate with all channels again.
So I guess my question is during the native error handling in that first aspirate step, if there is a way to get it to go to zmax without any custom error handling, OR if there is a way to make a channel patter based on what has volume in the tips already.
Thanks again for all the help! This forum has been amazing and so much great information!!
For your error state when you have a channel that found liquid level but the other ones didn’t, could you get that information out from the aspiration command? I think you can bind the output of that step to perform error handling and omit the channel that found liquid level.
1 Like
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.
5 Likes
Hi Nick,
Thank you so much for this information!! We were attempting something similar but in a different way but before we went these routes of adding this level of logic that was why we were asking if there was a native way upon error to lift the channels to zmax.
I am attempting to implement the logic you mentioned above and was wondering where I can find the ParseStepReturnForCancelledChannels library? I was looking for it and can’t seem to find it in our install.
Thank you!!
Unfortunately there is not a simple means of manipulating channel traverse height only on particular error scenarios, which is why I opted to demonstrate an advanced implementation.
Regarding the ‘ParseStepReturnForCancelledChannels’ function, that was a local submethod used by the demo method I posted (which only existed in the demo method). Unfortunately I wrote the above example as a temporary method draft only for the purposes of this post and did not save it.
I recommend copying the code from the screen grab and adapting to your needs.
Thanks.
-Nick
Ohh gotcha. Is there an issue if we keep the channels at zmax for the entire method? Just curious about that.
And thanks for that information! I will be testing his fix next week and will report back to you with my findings! Thanks and have a great weekend!!
Hi Nick! Colleague of ninjasquad31. Is there a way to change the height in which the channels go to upon an error for all methods run on a system? (not just particular methods or steps)
Thank you!
Hi Emily,
Unfortunately there isn’t an easy way to do this. If the above technique isn’t suitable for the needs of you and your team, then we can put you in touch with your local applications support team and figure out a plan that works to your preference for this particular case.
Thanks, and let me know what you think.
-Nick
Hi Nick,
So with a few tweaks, I was able to get the solution you presented to work! I am going to be doing a little more stress testing but so far I think we should be good now.
Thanks again for all your help!!
4 Likes