For my aspiration I use the workflow with customized errorhandling for each step. This means that I read the stepreturn and decide - based upon the MainError - what to do.
Everything is working in a happy path, but in a unhappy path I am a bit puzzled how to operate with the hardware error.
For example
Operator loads reagents but forgets to put reagents in the tube. This results for a reagents to a “hardware error” (02/54) and the recovery right now is to inform the user and to reload reagents. However, right after the recovery I get into the “Plunger is outside of permitted area”
My guess is that I need to perform a tip eject and a new tip pickup correct? That way I can reset the plunger inside. Or is there any other way to accomplish this?
Could you share a trace file? It appears the original error you were getting was the “Plunger is outside of permitted area”. So, repeat was throwing the same error. Trace file will confirm.
Typically, you get this error if there is a Z stall mid aspiration that was repeated without dispensing back to the source or resetting the channel in some way.
The recovery for this is that the aspiration SMT returns a false to the main method, this in it turn keeps it in the 1:1 loop I have for each reagent aspiration. The next aspiration is going to retry (that would be the idea anyway)
The subsequent error is :
P1: Plunger drive, Position out of permitted area.]) (0x28 - 0x1 - 0x80a)
What my spidy sense told me is indeed that I need to perform a reset in a way of the plunger and to my knowledge this can be done at two ways, either dispense or perform a tip eject. Although I am not a 100% entirely sure this last one is correct.
Would it be sufficient then to check in the stepreturn errors for the main error (hardware / 02) and screen for the plungerdrive error (slave / 54)
Checking the firmware reference shows me there are a few errors that could happen, but the scenario I am currently investigating (a user ignored instructions and put an empty tube on deck) the situation would be only hardware error, because the Z-steploss might be triggered rather than cLLD error.
the original reason we had the hardware error was basically a wrong teaching of the labware. We noticed that the position was off by 10mm (basically a grand canyon could fit here). So we corrected this
after triggering an error, the system goes into “Errorhandling by the user” and the SRV is being processed. All channels with an hardware error are flagged and stored in an array the size of the SRV. At the end of errorhandling these channels are joined to a channelpattern by the HSLExtentions library STRING and then those affected channels are ejected to the waste and new tips picked-up.
This workflow works great and resolves my issue 100%
