I’m having trouble with level detection for Eppendorf tubes. Setting up the well dimensions works for wells with flat bottoms, hemispherical bottoms, or V-bottoms. But an Eppendorf tube has a V bottom that doesn’t come all the way to a point.
I’ve tried to call it a V bottom, but I can’t find a setting that gives me anything resembling an accurate volume or even a number that is off by some consistent factor that I can correct for.
It seems to me that I can’t possibly be the first person who has ever tried to use an Eppendorf tube on a Tecan robot. Surely those tubes are ubiquitous enough that this problem has been encountered before. So I’m hoping that someone out there might be able to share the secret to getting accurate volume information from level detection in this type of tube.
This is why FluentControl has a better way to define containers.
Can you give examples of volume inconsistencies? I have for sure defined Eppendorf tubes in the past and not had too much trouble but at the same time I never needed to have a super accurate volume measurement. I just used V-bottom but never tried to go below ~30uL or so. Below that you will start to have some inconsistencies I’d say.
Fluent Control is way better in this regard. I feel like a significant percentage of Fluent errors are due to imprecise labware, container, device or site definitions.
In addition, the correct container definitions also help create incredibly great simulations that make it simpler to translate from Fluent to Fluent.
Also the Microscript is the best. Shame they eliminated it for the Veya.
It just depends on where I set the “Depth of Bottom” parameter, which is supposed to represent the distance from the bottom of the V well to the point where it becomes cylindrical. If I set it to 18.5, the actual distance tot he bottom of an Eppendorf from the point where it starts to thin, then it shows about 80ul when I put in 200ul. But it shows around 10ul when I have 50. So the volume reading changed by 70ul when the real volume changed by 150.
If I change the “Depth of Bottom” parameter then I can get it to be different, but still nothing that looks like I could back the real volume out without setting up some sort of calibration curve.
I would increase the diameter of the well since both of those measurements are low. I was more worried that at one point it was measuring too high and then at some point it switches to measuring too low. What you describe would indicate to me that the diameter of the well is too small. Post up a screenshot of your container dimensions in Evoware, I’m sure someone will have a labware definition that will get you something that works pretty well.
Unfortunately, FluentControl cannot run Evo instruments.
That looks pretty close to what Eppendorf says for their dimensions as found here.
I would raise that area up incrementally until you reach something that works for you. With Evoware you’ll never get something perfect, but you should be able to get something that works pretty well.
With FluentControl you build your vessel using multiple shapes with proper dimensions for each shape. So you aren’t hemmed in by just putting a cone under a cube, which is what Evoware is forcing you to do.
But I can’t use that with the robot I have. So it doesn’t help at all. And I will never buy anything else from Tecan. They have proven to be one of the worst companies I’ve ever dealt with after the sale.
They used to be great. Post-COVID they just haven’t bounced back. They had huge turnover with both FSEs and sales. It’s unfortunate, Tecans are great products, but I totally get the frustration. There’s a lot of experts on this board, so post up your frustrations and I’m sure there’s people here willing to help.
There must be some way to use firmware to get the raw liquid level data before the Evo software translates it to a volumetric value. This is practically a guaranteed work-around. And luckily the firmware ↔ high-level command translations are exquisitely documented in the pylabrobot repo.
discuss.pylabrobot.org is the new forum location dedicated to pylabrobot specific discussions. It sounds like you just need to extract z-axis values for liquid level data from firmware strings. It seems very likely PLR has something like this already you can reference.
i am curious what you are requiring in terms of actual volume measured vs instrument reporting volume
over the years, i’ve tried various models and settled on firmware commands to extract the “liquid height” detected,
and then an external application to build the compartment & total volume available
I can share the firmware commands after I’ve searched for the code - the result is a calculated height between the bottom of the tube & the tip height where liquid was detected (in 1/10 mm),
this height is then converted into the volumes associated with the different geometries for the different tube layers
The purpose is twofold. First off, I have several places where the pipetting command gives an error that there isn’t enough liquid in the tube. The stuff in the tube is precious or expensive so I don’t want to put extra just to make up the volume. So I have to pipette without level detection. I think that is an acceptable work around, but it seems like it would be better if it did especially because when it uses level detection it pulls from the top of the liquid.
The second reason has to do with a bunch of samples that have varying volumes. I need to bring them up to 500ul and then transfer to a filter plate. Since the sample volumes are all over the map I’d like to get close at least and leave behind as little sample as possible and I don’t want to have to equalize those volumes by hand.
I guess I could just tell it to aspirate more than will ever be there without any level detection, but again it just seems like detecting the actual level is a better solution if it would work.
Sorry, a bit let to the thread. I had help from Tecan to develop a script called “Set Compartment Definitions”. Basically we loaded a plate with different volumes of liquids along each row. The system would detect 3 replicates (I believe) across columns, average the recorded volume and output the results on the TouchTools screen. We then used these values to iteratively fine tune the compartment definitions to ensure the output volumes were consistent with the actual volumes we put into the plate. I think after 2 rounds in a PCR plate, we got the volumes pretty close to accurate. Of course we were sure to use a recently calibrated pipette when dispensing the volumes into the plate
Here is a screenshot of the setup:
(FYI I have a 34" monitor in portrait mode to make scripting easier)
Honestly would be a fun CI project to setup an algo that correlated the detection height with the volume in the well.
The real power with the EVO is with it’s incredibly rich documentation of the firmware and also the ability to customize the backend (since it’s super easy parse those text files.)
I used to use liquid heights for all sorts of troubleshooting and data gathering. Miss those firmware logs
I’ve heard people say this. But where is this documentation? I once had a need to aspirate more than one full syringe pull on a liquid displacement Evo. I was told you can do some firmware magic to flip the valves, reset the syringe, and get another aspirate cycle. I contacted Tecan but they were not forthcoming with the firmware documentation.
The only way I have got around this on an EVO is to setup the container definitions as a V-bottom, teach the z-max to the actual and on liquid detection run a short script that correct the overestimated volume via a fixed value that rough equates to any dead volume and overestimated container volume. You can run this volume correction as a VB or within loops in EVOware.
You can use these corrected values for more calculating dilutions more accurately. The accuracy is much better but there is very little you can do about estimating meniscus variation and correcting on liquid height and viscosity.
You could build more complex math ranges for correction, so effectively building a calibration but it depends on how far you want to push accuracy. It is generally easier to just switch labware that has a more defined shape. I ran into a similar problem and move to matrix tubes over eppendoffs to improve these calculations corrections.
Fluent Control is better at handling this and has a built in script to run volume calibrations so the method above partly replicates this on an EVO.
