Hi,
Currently on a critical protocol we have error recovery set to automatic recovery → go to bottom for both no liquid level found and insufficient liquid level. In the aspirate step we have a retract height of 5mm for air transport with liquid level following on.
This works fine when liquid is detected. The instrument finds the top of the liquid surface then follows down as it aspirates, then pulls 5mm up and captures the air transport volume.
I am wondering in the case of a automatic recovery at bottom what retract height is used. Does it use the 5mm? In most cases 5mm from bottom could (but not likely) be inside of the liquid. I know that during automatic recovery it does some automatic settings, slow pipette etc. I am wondering if it respects the retract height or goes to safe height for air transport retraction?
Thanks,
Colin
Hi @cwehrhan ,
For scenarios that recovery is set to bottom, VENUS will use the container depth as the retract distance. Which for tall tubes, this can lead to a long retract time if the swap speed is set to 2 or 5 mm/s. If the transfer is going to happen to or from a large container, then I would recommend using a 10 or 15 mm/s swap speed to prevent a long recovery.
1 Like
Amazing, I was hoping that was the case, makes my life easier, and makes logical sense.
Swap speed is set in the liquid class correct? Does it over-write this during auto-recovery? I’ve noticed it seems to move extra slow during auto-recovery.
Hi @cwehrhan ,
Swap speed is set in the liquid class correct. The speed is not overwritten, but the distance changes. For example: a plate that is 20 mm deep would take roughly 4 seconds to retract on error recovery vs a 5 mm retract distance that would take 1 second to retract with a swap speed of 5 mm/s.
Now this being said, the retract distance isn’t actually used for cLLD measured aspirations. It will retract up to and above the liquid level. Retract distance only comes into effect for fixed height aspirations/dispenses.
ah I’ve been passing in every parameter so I did not notice it “greys” out when CLLD is detected.
How is it calculating the retract then? The liquid tracking is notoriously bad for any complex tube, cylinder + cone as the firmware only has one acceleration parameter for both sections of the tube. It seems to take an average of these, making liquid tracking fall in or out of the tube easily as a large cylinder “weights” the speed of aspiration for a cylinder + cone.
This seems non-ideal. I would like to be able to add some buffer retract distance instead of relying on the variable geometry definitions of the Hamilton liquid following.
We spent many hours (possibly days) tuning eppendorf 1.5ml cylinder + cone (frustum) tubes to the exact geometry in the Hamilton labware editor to find that liquid following is completely inaccurate when following the exact geometry of a tube due to the single acceleration parameter. We have had to “manipulate” our tube definitions then empirically test high volume aspirations at different set points in the tube to make sure it does not fall out of liquid tracking.
Not only that but injection molded plastics are manufactured with draft angles which is impossible to account for in the Hamilton software, which further makes liquid following less reliable, which would make the need for a safe retract height more necessary.
Edit: I guess if it retracts to the height it locates the original liquid that would work, still some buffer would be nice. My above is mostly qualms with the single aspiration speed for liquid tracking
Totally agree, the liquid following can be a pain. It would be ideal to set the speed as an array, if there’s only a set speed without acceleration available (as is the case).
Additionally, the volume measurement is not reliable, and depending on sumerge depth an insufficient liquid error may be thrown.
I have handled this in the past by meticulously plotting volume against liquid level over the full range and calculating an ideal depth without liquid following.
With Eppendorf tubes, there is another issue, that they can vary in their z-position substantially - so it is necessary to include a certain tolerance.
1 Like
This would be really nice, I guess you could carve up your own custom firmware commands to do this but it would be a pain.
This is essentially what pylabrobot is doing, measuring actual volume in the tube at set points. Open source so you can share the findings and only has to be done correctly once.
True as well, but for bottom then it’s good to just do a z-touch off dispense inside custom error handling if a CLLD dispense fails.
I could probably do a long long thread on how broken liquid following is for these somewhat simple tubes, eppendorf 1.5mL with the cone base. There’s even a completely ignored/forgotten/never used parameter in the firmware in the C0AS command, zr#### (Tube 2nd section ratio). I wonder if it just never really worked out. I am not entirely sure even if you were able to add draft angles and correct some of the geometry issues on the software side if you could fix the liquid tracking for these “complex” tubes with the current hardware. You really need to be able to dynamically set the tracking speed per container segment. I think this might be possible on the next generation fluid motion pipettes but unsure.
1 Like
I’m almost at the point where liquid following is a negative. Falling out of following is far worse (aspirate air) than just aspirating at bottom and having some residual liquid on the outside of your tip. For tubes you run the risk of dunking the channels though…
With the current state of things, liquid following is only relevant in containers without any cone or with the same angle throughout.
I am fine with workarounds, be it in Pylabrobot or coded in the GUI. It would be nice to not be mislead into thinking that liquid following is actually reliable as is.
Another thing that relates to this is that the volume calculation (in Venus) is just awful. In case of precious samples or reagents, there shouldn’t be the need to provide substantial extra volume. Here also calculating the actual volume from detection height combined with aspirate all has been a gamechanger for me.
2 Likes