@mrthorne just an update after contacting Hamilton helpdesk about the tips rack issue.
My protocols are set up to have two racks of 50ul tips. When I start the protocols with half a rack of tips, for example, and need more than that half, the robot starts the protocol as usual and then as it runs out of tips it stops and gives an error, instead of moving to the second rack. I’ve contacted the helpdesk and their answer was:
“Unfortunately, what you are describing is a limitation to the software. The only options will be to start with a full rack or reload when prompted, though for the latter the instrument will assume you have reloaded a full tip rack.”
So, apparently the robot only goes to a second rack if within a protocol it recognizes that it needs more than 96 tips. Otherwise, it is unable to use a new rack, even if it is available.
This is a problem as most of the times the protocols do not use an entire rack of tips and the number we use are quite variable from run to run. Opening the robot during a run increases the chance of contamination, and it is annoying having to hang around the robot waiting for it to complain about the tips when there is another full rack available. It would be really good to see some changes in regards to this in the future.
Thanks.
Awesome feedback @tribeiro, thanks for taking the time to get back into this. A couple thoughts:
Normalization improvements:
- Negative diluent control: This is interesting and seems like something we could add as an option into the normalization step for sure.
- Forced 50s and 300s on the deck: Since the normalization input file could dictate that 50s and/or 300s be used (for larger normalizations), and we don’t know that till run time, the original intent of forcing both is for “just in case”. But if you know ahead of time you won’t have any large volume normalizations, it seems reasonable to be able to disable 300s being required. We just need to make sure to do appropriate error handling at run time if a normalization input file DID end up dictating 300s would be necessary.
- I’ll make sure both of these get in front of our product manager.
Run-Time Improvements:
- Empty Input File(s): This is on our roadmap for an upcoming release. Might not be the next one (3.4), but certainly by the end of the year.
- Visualizing Wells: I have some ideas for how we might achieve this without it getting too clunky. Do you feel this is most valuable only for tubes? Or for any well, in any labware on the deck that will get used in the run?
- Replicates horizontal pipetting: I might need to see a specific example so I can see what edge cases may have been missed. We can DM on this.
- Multiple tip racks: I chatted with product support and took a look at your protocol and better understand now. Despite having two deck sites as capable of having tips, we “compile out” at run time labware that is unnecessary for the run. But, like you’re finding, this comes at odds with tips if your rack has less than ‘expected’, and we’ve compiled out the other rack location. There’s room for improvement here for sure, we’ll see how we can make this better.
Other improvements:
- Handling volumes greater than tip size: This, or something similar, has been brought up several times (also in this thread). One of the main hesitations here is how to properly communicate the potential for contamination if we’re headed back to get more volume to finish out a “full transfer”. There are a few other edge case details we need to work out also.
- Go to bottom: Definitely see the benefit here and am hoping we can get auto-error handling into the roadmap soon, which would immensely help here. We do have some things coming mid-summer that may be able to use as a stop-gap…
Again, thanks for all of this great feedback!