Hi all,
I’ve been having some issues with volume measurement into a MicroAmp Endura Plate. I’ve developed a method to transfer up to 50uL of volume from 0.5mL matrix tubes into the wells of this plate (technically 2 segments, a cylindrical segment and a sharp V bottom segment). Even after making some adjustments to the definition in labware editor, I still consistently get high volumes at the lower end (anything less than ~40uL). The protocol is set up to always aspirate 50uL from the matrix tubes, but we want to make sure that the volume that is dispensed in the plate has at the very least 20uL. However, any volume measured below 40uL will consistently be measured 5uL higher (so if 20uL was dispensed, the measurement would be around 25-26uL).
Essentially, there is an aspiration step from the tubes, a dispense step into the plate, and then another “aspiration” step (aspirating 0uL) to get the height of the liquid in the plate wells, bound to a return value variable. Get Last Liquid Level was also had a step return value variable that was applied to LIQUID_LEVEL_ReturnVolumesFromLiquidLevel of STAR Channel Tools. Since I wasn’t able to get that to work, I tried emulating the code in this thread (with some updates to loop through the sequences in the plate) to compute the volume of the container using DevComputeContainerVolume. Still, I get the same result after subtracting Z height from the measured height of the labware.
Are there any other ideas I could try? I have gone into labware editor and made some updates to the .ctr and .rck files based on manual measurements and schematics of the plate, with varying degrees of success. Based on the shape of the container, I’m not sure if I’ll be able to get it closer than 5uL. I’ve seen some ideas on this forum about applying volumes based on lookup tables, but I’m not sure how to go about it. I’m also thinking if there is a way to apply a separate formula for calculation to do a correction at volumes less than 40uL.
Our last option is to just give up (for now, until the next iteration) and just let the lab decide on how to account for the inaccuracy of the measurement on our documentation. For clarity, it is ok that we have the discrepancy since we already know that this function is inaccurate (we’ve used it in our protocols before, but at much higher volumes). it just doesn’t sit well with me that there’s such a high discrepancy at low volumes.
