@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.
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…
I was wondering if any of these suggestions have been integrated into the ML Prep software. My colleagues and I are particularly interested in the use of Empty Input files for a couple of our methods.
I’m creating a method that will do hit picking to be able to do both fixed 15uL aliquots into matrix tubes as well as do variable volumes for anywhere from 15uL and above. It will require both 50uL and 300uL but I’ve discovered that I’d likely need 2 worklists to be able to use both tip types. I will not always need one or the other, however, so it would be useful to input a dummy worklist. Either that, or if the hit picking step could determine which tips were needed based on volumes to be dispensed.
My colleague is creating a reagent aliquoting method that will use 1 type of reagent with a max of 144 tubes. They do not want to utilize the same tips throughout the entire method, but also do not want to discard tips every time. We decided to create separate worklists for each reagent trough in order for tips to be discarded after each trough was depleted, but we are encountering the same issue with not needing to use all the reagent troughs based on number of samples. Does the ML Prep have the option to eject tips after a certain number of cycles?
Using empty worklists to skip hitpicking or reagent from file steps is not quite released yet and should be included in our next minor release (3.4.0).
What you are eluding to is correct. Except for steps like serial dilution or normalization which can purposely specify multiple sizes of tips, standard steps can only use one tip type. So in your examples where sometimes you use 50s and sometimes you use 300s, you will in fact need to use two worklist steps at least.
In your example of the reagent aliquoting method using a max of 144 tubes, you mentioned not wanting to use the same tips throughout. Is that throughout the entire protocol or just throuhout the entire step? While there is no option to eject tips after a certain number of cycles, is there a specific threshold or otherwise that you need to eject tips and grab news ones?
I think we decided that we would make 2 separate sample aliquoting protocols to use either 50uL tips or 300uL tips so we could use separate worklists.
I’m not as involved in the reagent transfer method, but it was originally comprised of one step, which is worklist based also rather than having users select samples at the beginning of the run. This was so we could vary the volumes (we would be working with 1mL-1.5mL so would have to go in some tubes more than once to get to that volume). The threshold would be one reagent trough, so at least 60-80 cycles before changing tips. However, in the end I believe that we decided we would use the same tips throughout the reagent aliquoting method since there didn’t seem to be a noticeable change in volume or danger of over aspiration (though more testing needs to be completed to confirm).
Ultimately, both these methods are low risk so it’s ok if it’s not completely streamlined, just wondering if there were ways to make them more efficient
It does sound like having the ability to skip certain worklisting steps then would be your best bet for further optimizing, which like I mentioned should be coming soon.
Another alternative would be to script something against the Prep API that would check the worklists you were submitting, and then disable certain steps it knew there was nothing to be done for, but that might introduce more complexity than you want for the workflow having something run off the Prep ahead of time. But it’s a thought!
I have a question regarding multi-dispense and using files / external inputs.
Ideally, I would like to:
Aspirate a master mix once
Dispense it into multiple wells (multi-dispense)
Drive which wells are used (and/or volumes) from a file or external source
From what I understand today, I have to choose between:
Add Reagent / Replicate Samples → supports multi-dispense, but with the same volume per dispense and with the wells/samples defined inside the method, or
Hitpick worklist / Reagent from file → supports different wells and volumes from a file, but behaves more like single-dispense per aspiration.
What I’m wondering is:
Even if all dispenses use the same volume, is there any way to use a file just to define which wells / how many samples will receive the reagent (i.e. drive the Add Reagent / Replicate Samples targets from a file)?
Alternatively, via the API, is there any way to change the number of samples or the selected wells for an Add Reagent or Replicate Samples step right before the run, instead of hard-coding them in the protocol?
In short: is there any supported or recommended way to do “multi-dispense from a file”, or at least “same-volume multi-dispense but with targets defined by file or API”?
@carlosibo you are right that neither of the “uses a file to drive” protocol steps support aliqoting/multi-dispense yet (though with enough community interest this could be prioritized in the backlog). So for now, the API is probably your option.
You could approach this two different ways:
1. Use a plate mask via How Many Samples
Define your worst case scenario of targets (say all 96 wells of a plate) in your protocol.
Then, apply a mask on that labware with the How Many Samples step.
Next use a small script against the API to run your protocol and then submit at run time (via the How Many Samples selection) which wells you want to receive your master mix.
This option gives you a little bit better experience if you want to use the same protocol and sometimes you want to run via the API and sometimes you want to run with the UI (with your operator selecting which wells to use).
2. Script the exact target selection via the API
Alternatively, instead of using How Many Samples, have your script and the API define the exact set of target wells for the protocol step each time you run.
This is akin to “hard coding” it each time you run and might give you more flexibility via code, but puts more of the onus on always using the script to initiate the run and choose the wells.
Both of these methods should work with either Add Reagent or Replicate Samples. The choice depends on if you want the calculation done for you on how much master mix to use.
Add Reagent will treat your master mix as a consumable and will therefore calculate how much needs added at the beginning of your run (and handle requesting reloads for you if necessary).
Replicate Samples will also work, just with less auto-calculation for you.
Just a quick update that v3.4.0 is now live and addresses a few of the QoL items discussed here. You can grab the installer here.
A few highlights based on feedback:
Empty worklists to skip hitpicking steps. As requested by @tribeiro and a few others, you can now use an empty worklist (header only) to skip hitpicking or reagent from file steps at run-time instead of needing separate protocols.
Retract distance exposed for aspirates. When using fixed height aspirates, the retract distance can now be specified. This is helpful for making sure you come all the way out of liquid before air transport is aspirated.
Lazy loading of steps in edit/preview screen. Steps are now lazy-loaded here to make navigating long protocols a bit snappier.
CORS origin configurations. For those using the REST API via not just IP addresses, this should prove very useful.
