Does anyone else have issue when trying to use this function? It seemed like a great tool to use when trying to validate labware, but I only seem to get negative volumes or really really small volumes when using it that are definitely way off a known volume I’ve placed in a known labware container
I use dry 300uL unfiltered tips when using the function btw.
I’d have to do some digging to find an example of how best to use this function, but in the meantime, I wanted to highlight the STAR Tools suite of libraries. If you import the demo pkg, you’ll have access to several submethod libraries for more comprehensive channels, pipetting, tips, and MPH functions. The Pipetting Tools smt includes a Find Liquid Level and Calculate Volume for Height command that should work out for you.
Ok, I now remember that prior to the STAR Tools functions, instead of using the MeasureContainerVolume2 function (likely because I ran into similar issues), my approach was to use the step return to get the liquid level found, calculate the height of the liquid in the container and then feed that into the HSLDevComputeContainerVolume function. See this link for an example method. My apologies, this was written before we had a proper variable naming convention.
The STAR Tools function is much more straightforward though.
Generally speaking, the volume estimates are typically going to underestimate the volume for a variety of reasons (meniscus of the liquid, labware definition, etc.). For better volume estimates, avoid using a “v-cone base segment” in your container definition as the calculation for geometry is not correct and will underestimate the volume. Replace it with a “v-cone” with a smaller lower internal diameter.
I’d love to get all resources like labware, libraries, and methods hosted on a server and accessible through a command line tool with managed dependencies and I plan to start working on that as soon I am done with the PyLabRobot paper.
Hi all, the use of the Hamilton file repository was only meant as an interim solution in lieu of an alternative. As soon as you set something up, I’d be happy to transfer the files from Hamilton there instead. I agree that having one place for users to go to would be the most convenient.
What I’ve been trying to do is have the robot return what it “thinks” the volume in the container is when using cLLD and it throws an insufficient volume error. You could then gate the error handling in a more logical way (e.g. if the volume to be aspirated were 100 uL, and you know there’s a underestimation of roughly 20 uL, any error thrown when the return value is >80 uL would result in aspirating from bottom, where <80 would be an actual error dialog where the user needs to refill and repeat or exclude and go to the next sample).
The trouble is getting the calculated volume from the aspiration step and not a separate command. This volume is clearly stored somewhere, wondering if there’s a library or firmware command to get to it. I’ve used this measure volume library before but it can really slow the method down to try and do this in every well of a plate.
That’s because the “volume check” during an LLD step is checking the found height and comparing it to the distance that it must travel. If the found height is less than the distance it needs to move during the aspirate step, then it flags an insufficient liquid error. If you use the step return on the aspirate, you would only get a return of heights.
You’d need a separate function such as the DevComputeContainervolume from the HSLDev library (shown in the example method I shared above). Given some of the inherent limitations in the Hamilton labware editor, you could only get an estimate of the volume so if that isn’t accurate enough for your purposes, there are other options. For example, with the returned height, you could compare the value to a separate lookup table where you have a list of heights and known volume for each height that you measured.
But on that note, @EricSindelar_Hamilton how are labware files validated when they come from Hamilton? I’ve received a few labware files from our apps person and while most of the time they work perfectly, every so often we’ll get one that just isn’t working with cLLD well, likely do the the container geometry being off. Can you share the protocol Hamilton follows for validating a labware file?
I don’t have a copy of our software team’s internal procedure for validating or including labware in a software release. For the applications support team, they get training on the labware editor and they modify existing labware or define new labware as needed for their specific project. As is the case with creating/modifying liquid classes, there may not be the need or opportunity to completely vet each parameter for the definition itself - for example, the system someone is working on may not have a gripper so the external segment geometry wasn’t defined. In other words, the definition may not be applicable or transferable to other setups.