I was wondering how exactly the 5-minute timeout is calculated (When is the command send). I want to perform an aspirate step with two channels, consecutively from the same position. My mixing flow rate needs to be low, this results in a 4 min mixing time for one channel. Would this work?
Or would it time out because the overall aspirate step would be then around 8 min since two channels are used?
Hi @FabienKohl ,
Iām pretty sure the timer starts on the firmware side and begins when the system receives the command.
You can double your time since you are using the same source location by using two aspirate commands with different channel patterns. First one with ā10000000ā and the second one with ā01000000ā. Visually it will perform the same movement as the first channel will mix/aspirate then move out of the way for the second channel to mix/aspirate.
Late to this thread, but I wanted to react to the last messages (and it seems like I canāt create a post).
@BrandonBare_Hamiltonās explanation is the clearest description Iāve seen of the failure mode: the drive stops wherever it was when the timeout hit, so the retry compounds it rather than repeating it.
This isnāt Venus-specific. Iāve been working on PyLabRobot, and the same shape shows up there, a command whose physical effect canāt be established afterwards, where retrying is the wrong move. @Pascalās fix earlier in this thread (flag the channels, eject, re-pick) is a manual version of what an automated layer would need to do.
One question for the people running these systems:
Outside a documented case like the 5-minute timeout, how do you actually decide whether itās safe to retry? Does the instrument tell you enough (sensors, status queries, drive positions) or does it come down to a trace file after the fact, or someone opening the deck?
In general, hardware errors should not be taken lightly. In my assays - all under IVD regulation - it was decided to let the run abort due to an hardware error. This because our validation process and unhappy path testing showed that hardware errors would happen whenā¦wellā¦hardware would error out. The timeout is never triggered here and if we see a hardware error, itās because we made that happen. An example would be not to be āteachingā the system correct so Z would be higher-up. A HW-error on retry would happen when the vial of reagent is empty. Thatās something I do not wish to recover automatically because it needs to be fixed.
Did I understand your question correct here?
Yes, you understood it. Thanks for your reply. Your answer resolves a big part of it.
Automatic recovery isnāt desirable, if I understand correctly. If thereās a hardware error, the run should abort rather than continue on assumptions. In an IVD context especially, it makes sense that the remedy belongs in the validated process and requires someone to fix the underlying cause.
What Iām still trying to understand is what happens after the abort. Before the run can be repeated, the actual state of the deck and the samples has to be established ā the routine you described earlier in this thread is a codified version of exactly that, for e.g., flagging the affected channels and ejecting to waste before new tips are picked up.
Is that determination, plus the root cause and whatever was done before the rerun, captured somewhere durable enough that someone could reconstruct months later what happened to those samples? Or does a good part of it stay with the operator; and is that not really a problem in practice?