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.
IIRC this is how I implemented this last year. We didn’t need a very accurate number so this got us very close and then we applied a correction.
Definitely, or use that inaccurate number as the baseline if it’s not critical check but more of a metric to help troubleshooting
I’m only trying to quick verify without 0.5uL. I didn’t know this STAR Tools Demo pack though, thanks @EricSindelar_Hamilton.
Anyone wanna upload their labware test programs?
@EricSindelar_Hamilton what is this download share link tooling you are using???
In response to requests on the Library Downloads thread, I set up a folder on Hamilton’s Resource Center to compile and organize the materials I’ve been sharing on this site.
See this link for the shared folder I put together. Anything with Hamilton as a prefix are folders containing content from Hamilton.
I also created a User Created Content folder where anyone can upload files, but I would understand if such content would be better hosted on this site instead.
Right but The URL says “https://download.hamiltonsupport.com/wl/…“
If I or someone else here wanted to set up a share site like this how could we mimic your easy access download website?
As of now we love how much actual code and downloads you are sharing but how can we enable, Biomek, Lynx, Janus, PE, Fluent, etc Automators to do the same with helpful tools they’ve made?
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.
Want help? For starters we could host files on ipfs & add a link aggregator wiki to the forum
Yeah, if anyone wants to host relevant files on a server I can basically treat these servers the same way mirrors are treated in conda or apt-get
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 does this look like set up? When someone wants to share something do they need to know how to use the ifps or @Stefan can it be some sort of button set up in the tool bar?
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.
Ah good call. I could make a submethod library that feeds in that returned height along with the labware ID and outputs estimated volume. Not sure how quick this would be but definitely doable.
Better have solid qualification and testing done on that labware definition though since all those calculation are assumed in that .ctr file.
Hence the need for a peer validated labware DB!!!
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.
awesome, appreciate the insight!