ML Prep suggestions

Hamilton (Microlab Prep)
1

Hi all,

Seeing as the MLPrep is a relatively new platform and is still ramping up in terms of usage and reach, I’m hoping to start a thread where we can provide some feedback into features that would improve QoL for the users. Seeing as there’s a massive Hamilton presence on these forums, I think this would be a great way to improve the Prep’s utility in labs, new and existing.

I’ll start → Give us variables and the ability to do some math on our side! I don’t think I’m the only one who finds it a little tedious to change the volume for 8 different aliquot steps all individually, all the time with the method editor jumping back up to line 1 of the script every time a change is applied. I swear that one of my arms are stronger than the other after having to hold it up for so long applying changes on that touch screen.

P.S.: I love the ML Prep and this criticism is 10000% constructive in nature!

1 Like
2

Thanks for starting this thread! I’m the team lead for the PREP sales side, and one thing the sales team has been tasked with is gathering suggestions on features we could add, tweak, or remove to better the experience, so great timing on this. Glad to hear you are loving the PREP!

Question: would you want to be able to select the 8 different steps “checkbox” style, and then say "change volume → [ enter new value])?

Also, I like the idea of you not having to scroll down to the last step.

(For the arm strength, one “hack” I always use if I’m working on the PREP for a while is sticking my bluetooth dongle into the USB slot and using my wireless mouse and keyboard to navigate/type!)

Please keep the feedback coming!!

3

Any sort of “bulk editing” would be nice; loops, variables, or even checkbox style like you suggested.
One thing that variables would be nice for is reagent calculations. It looks like the Prep uses only a plain 5% overage for calculations, and maybe a very small dead volume. However, it overlooks pre-mix of the source trough when making these calculations so there are some situations where this can cause over-aspiration events. For instance if you need to alq 500µL into multiple wells, but use a pre-aspirate mix on the source trough at 750µL, you would be causing issues on anything less than 8 samples. Using a pre-mix volume ≤ transfer volume is always an option… but the mixing becomes inefficient at larger sample sizes. Bit of a tricky problem within the current capabilities of the software.

And I elaborated a bit on the arm strength aspect - its not that bad I was just being dramatic :slight_smile:

3 Likes
4

My team and I ran into an issue with the MicroLab prep that I want to raise awareness about:

The default aqueous liquid class on it has an air travel volume default of 5uL but no setting to adjust what height it draws that extra trailing air cushion at after aspiration. The default liquid class also has the “Jet” dispense setting that clears the entire tip contents.

If you’re dealing with small source volumes at fixed aspirate heights (where liquid level sensing won’t work in many plate types) you need to dial that travel volume down to 0 and save a custom liquid class for that or it always pulls that extra 5uL of “air” volume from the liquid in the source well and dispenses it.

My team has also even noticed this behavior with liquid sensing enabled and working at the default -2mm liquid level aspirate setting with volumes <20uL.

I’d love to be able to set my new custom “aqueous-no-extra” liquid class I’m now using for most of my methods as the default. There should also be some kind of logic in the software for an alternate “zero travel volume” default liquid class when aspiration is set to a fixed height and/or aspiration volumes are below some threshold volume.

Unrelated: is there any way to enable pipetting from/into plates that are on the heater/shaker position? Or handle lids? The HHS integration is a nice idea but not as useful as it could be without those functionalities.

2 Likes
5

Thank you for sharing this! I’m sending this over to the product management/software team this morning.

The requested changes I’m hearing here are:
–ability to set which liquid class is the default
–ability to either set when the air travel volume is aspirated or (and) have it automatically remove the transport volume when pipetting in certain parameters.

Is that a good summary?

For the HHS piece, Hamilton doesn’t recommend pipetting into/from plates on the HHS on any of our systems due to the risk of a) damaging the HHS [if chemicals/reagents got into the unit) and b) causing fires. There have been times where people set up their protocols incorrectly and pipetted volatile liquids directly onto the HHS without a plate in place, which caused a fire. So from a liability and best practice standpoint we actively discourage that.

On the PREP, since it is a little more streamlined (or locked-down), we just completely disabled the option, particularly since you can’t do a tap-off to confirm that the plate is present before pipetting.

The goal here was to make it “undergrad resistant” [sorry to any undergrads reading this…feel free to mentally substitute “PI resistant” if it makes you feel better] and let them use/program with next-to-no training (and not risk burning down their lab).

RE: lids. I remember asking about this, and I honestly don’t remember the reason we don’t handle lids currently. I’ll ask about that as well.

6

Michael: thank you so much for your quick response! I think your summary of requested changes is spot-on. That all makes sense regarding the HHS too.

Cheers,
-Scott

1 Like
7

I know that I’ve shared this privately but an API would be awesome.

I understand that it’s standalone but it seems like the ability to at least pull information from the system after a run or send it information would be super useful.

Also at the moment, is the end of run report only a manual download?

1 Like
8

Hi all,

My team has recently acquired a ML prep and we like how easy it is to use which makes it simple for anyone to pick up. However, we’ve found a few limitations of the ML prep which has been slightly frustrating.

Some of the limitations of the Prep are:

  • You are unable to use sample select setting that cause steps to be skipped from the sample select page. This limitation forces us to create multiple protocols for the steps you wish to be skipped.
  • You are forced to select tubes or plates as the variable in the sample select page, you are unbale to select reservoirs.
  • You are unable to program the Prep to continue to replicate samples until the source runs dry.
  • You are forced to use the sample tip size throughout a serial dilution, you can’t start the serial dilution using a 50 μL tip then switch to a 1000 μL tip in the sample serial dilution step.
  • When using the reagent from file feature:
    • You are unable to use the 8-tip head.
    • You are unable to use multi dispense.
    • You are unable to add different reagents from a single add reagent step.
  • The ML prep will just pause when it runs out of tips, it won’t flash or give any warning, it is up to the user to periodically check.
  • The ML prep cannot be programmed to automatically save the run report after every run, the user must manually save.

We love our Prep and it has already proven its worth, I’m only providing the above criticism as I want to see this platform become more useful into the future.

Cheers

1 Like
9

Hey @decoy , thank you for sharing the feedback!

The good news is that some of the things you mention are actually doable/available in the software today, or have other ways of achieving similar results.

I can share some of that here, but it may be easier to hop on a call to walk through it/share my screen with the software so you can see it?

If you’d like to do that, shoot me a DM and we can connect via email :slight_smile:

1 Like
10

Hi,

I don’t know if there are new posts with further suggestions, or if this is the most recent one.
I’ve been recently trying to validate the MicroLab prep at my workplace, and it has been a nightmare. I am disappointed with the lack of capabilities of the robot and I’ve got very frustrated during the entire process. We have used the Qiagility robots for years and the MLpreps seem to be way more limited and finicky in every aspect.
I will list my biggest complaints and a few suggestions below, in a hope that I can get some insights and that some of the suggestions could be implemented in a next release.

  • First of all, you have to do all the protocol set-up at the instrument. There is no computer interface where you can simulate or play with the protocols from the comfort of your desk. It would be nice to be able to play with it in your desk to get it working and then sit in the lab to test it.
  • The thing that annoys me the most with the MLpreps is that the robot is unable of transferring volumes that are greater than the tips size - if, for example, you ask the robot to transfer 100ul of liquid using the 50ul tips, it won’t! But it won’t tell you either, it will do one transfer of 50ul and it will move to the next step. I find this a bit unacceptable for liquid handling robots and think that it is supposed to be the bare minimum a robot can do (either automatically choose the tip size it needs, or calculate how many trips it needs to do). This means that unless you have standard volumes that you transfer every single time, it is a big problem - like when making up master mix for varying number of samples, for example.
  • Following the complaint above, you can only pick one tip size for each protocol and you have to pick a size. So, considering that the robot is unable of doing multiple trips automatically, you have to either create multiple steps for transferring different volumes, or do everything by hit-picking and manually break up the steps in multiple lines in the input file.
  • The other big issue I see ( and I hope this gets fixed anytime soon), is that even if you have two tip racks in the instrument with same tips’ size, it won’t be able to pick tips from a second rack once the first one is empty. The weird thing is that the robot recognises that you have two tip racks, but it is unable of either seeing which of the racks has a suitable amount of tips, or picking from both of them (only picks from the first one). So, if there isn’t enough tips in the first rack you have, your protocol will be paused half-way through saying you ran out of tips, even though you have another rack full of them.
  • In the normalisation protocols, you are stuck with one single volume and with tip sizes of 50ul and 300ul, you can’t use the P1000 even if you are doing big dilutions.
  • When building a protocol, if you are required to add an input file, you can’t give an input file that is empty, or that has the heading but no samples. So, if there is any specific step that sometimes has samples, and some other times don’t (dilutions for example), you need to create two separate protocols.
  • You can’t set up the MLpreps to look for liquid at the bottom of the tubes by default (this is also a improvement that I expect to see soon). If you don’t have enough liquid in the tube (usually around 40-50ul) for the robot to recognises it, you will have to be watching the run to wait for when the robot prompts a box, so you can choose to look at the bottom of the tube.
  • If you are doing normalizations, there is no easy way to add a negative control of your diluent. You have to add another step (add reagent), and you can’t use your diluent tube in any of the other steps of transferring things.
  • At the beginning of the run, there is no easy way to visualise which tubes and wells are required, you can see which racks you need and the general places you are supposed to have stuff, but that’s it.
  • Another thing that I’ve noticed and could be improved in the next release is that when you are doing replicates, even though the robot gives you a choice of distributing it horizontally or vertically, it always does it horizontally, no matter what you choose. And that slows the pippetting time a bit, especially when using the two independent channels.

I think those are the main things that I struggled with when building my protocols, or still struggle now that I trying to run them. Not to only complain, there were some good upgrades on the most recent release (like the ability to drag and drop) and some cool features in the MLpreps (to be able to disable steps, to create users, to connect to the network, to be able to simulate protocols in the machine, and especially the capability of pippetting multiple samples at a same time). I just wanted to share the experience of someone that was used to using another liquid handler, had to validate a different one, and that got frustrated about the lack of some basic features on the MLpreps.

Anyway, I hope this post can be somewhat useful for people thinking on switching to the instruments or to give the Hamilton guys some new ideas/feedback.

Cheers.

2 Likes
11

I have a very similar experience with these types of challenges with the software, especially with the management of liquid classes. Protocols take a significant amount of time to get right, and bench scientists are struggling to achieve the independence in protocol development that is advertised for the system. Once a protocol is locked in, it has been robust, reliable, and accessible for operators, but expanding the user base and breadth of protocols has been a challenge.

Coming from using the Waters Andrew+ for a large userbase, the interface and development experience for users feels like a big step backwards from there.

12

luckily, rick fixed all stated problems in the pylabrobot ml prep integration.

it’s good hardware, we just need a coding interface to use its full power!

1 Like
13

Hi @tribeiro, great feedback. I’ll see that the comments make it to the product managers for the product, but let’s see what we can address here.

Procotol setup off instrument: This is a common request, and one that is being worked on. In the meantime, Hamilton does offer a stop-gap solution which is called a “Preplet”. This is a small mini-PC with touch screen that comes with the software pre-installed that you can take wherever you like. You can plug in your own larger screen, and even attach it to the same network as your Prep and drive the instrument remotely.

Volumes greater than the tip size/one tip size per protocol: I might need a little more clarification on your use case here. It sounds like you may want to define a different volume per transfer within a single step (which you elude to needing a hitpick worklist to achieve, which is true). Intentionally, to prevent damaging the internals of the channels through over-aspiration, the volume you can aspirate is limited to the volume of the tip that is used in that step. Performing multiple dispenses from a single aspirate is achieved through the Add Reagent or Replicate Samples steps, although the aliquots for those must be of the same volume per dispense.

Multiple tip racks not being consumed: This one might need your protocol submitted to the Prep helpdesk so it can be looked at. There were some issues with all tips being consumed with earlier versions of the software (2.1.x, 3.0.x) that should have been resolved, but it sounds like you are on a pretty recent version (latest is 3.2.2). There might still be an edge case that needs further look-see.

Normalization limited to 50µ and 300µ tips: Definitely would like to know more about the use cases for higher volume normalizations so we can get this functionaly developed as needed.

Using an empty input file: If I understand correctly, you’d like the ability to submit an empty file to skip a hitpick or reagent from file step? That’s an interesting idea and doable. We just need to ensure that it was intended to submit an empty file for that purpose and not done accidentally.

Automatic “go to bottom” pipetting: Automatic error handling in general is probably what you need here as there is not currently an exposed way to automatically respond to an error dialog. This is work that has been discussed but not formally added to the roadmap (yet).

Negative diluent control: Like the normalization comment above, definitely would like to know more about the use case so we can see about adding the functionality.

Visualizing wells used within the upcoming run: The load time interface which shows where to load labware and consumables (including number of tips, and volume of liquids) is about as close as this comes today. It’s an interesting request though. Would seeing just an overall map of everything that will be used be enough or would this also need to be reflected per step to know if wells are used multiple times within a protocol?

Replicates only pipetted horizontally: This is another one we’d like to see your protocol for since there was some odd behaviors with how replicates were being pipetted that were fixed circa v3.2.1 and we’d like to make sure we covered all the cases.

@Sean_M we’d also like to know more about any issues you’ve encountered with liquid classes and if you’ve tried developing them on your own or if you’ve had any successes or failures working with our product support team to assist any troubles you may have had.

Thanks for all the great feedback!

14

Some liquid class challenges I’ve observed the users having is first around the file structure. There was confusion and some chaos early on in adoption with scientists making global changes to liquid classes rather than just to their own protocol.

The default classes and wizards can be a little confusing and don’t seem to set them up for success. The pipette speeds have been high with large air gaps, especially with low volume tips, and made it difficult for scientists to produce good qualitative pipetting results without assistance. There has also been confusion about the dispense position selection and understanding that is changing the calibration curve through that selection. Given the ~50uL limits of the cLLD, dispensing with respect to bottom is frequently a requirement, even if the well is occupied. The software then selects a cal curve that assumes an empty well. This is challenging to explain to scientists to select/create a liquid class cal curve that is a duplicate of the original class, but with the cal curve copied from the free dispense option. These “hidden” nested liquid class cal curves for each tip type and positioning selection all captured by one liquid class name have created the unfortunate “black box” and “too much hassle to bother” impressions by lab staff and managers. At that point it falls to automation staff to support the MLP development and sort of defeats the purpose.

15

The TLDR version:
Would love to explore this some more, and our product support team would be the best place to start so we can get some further clarity on where there might be either a functional gap or a knowledge/training gap. Or if it’s related to the second point below.

The pipette speeds have been high with large air gaps, especially with low volume tips, and made it difficult for scientists to produce good qualitative pipetting results without assistance.

On our roadmap for this year is offering an enhanced solution for this:

Given the ~50uL limits of the cLLD, dispensing with respect to bottom is frequently a requirement, even if the well is occupied.

Which would allow for an “in liquid” liquid class to be used even when dispensing “out of liquid” or to very small pre-existing volumes.

The longer version:
Liquid classes are absolutely one of the more challenging aspects to get dialed in, and with the Prep UI there is a balance being struck with obfuscating away the details of selecting an exact liquid class with still being able to make those tweaks where necessary. As has been discussed on this forum at length, this concept of ease of use vs flexibility is a tough one.

There was significant validation effort that went into the default liquid classes that can be found today in Prep. They were based on those “tried and true” liquid class parameters that can be found in Venus, with small tweaks and adjustments based on the information that came out of the validation effort. The liquid types themselves (i.e. Aqueous, Blood, Beads, Serum) were tweaked and consolidated where no distinguishable differences between the existing Venus classes could be found or justified via test.

The goal of this effort was first and foremost to reduce (but not eliminate) the amount of tweaking or liquid class copying (and then tweaking) that would be necessary. This also would hopefully allow for the goal of being able to obfuscate away things like correction curves and overrides (but still expose the most frequently adjusted parameters).

A user’s selection of settings throughout their step setup will result in a liquid class automatically being selected for them with the additional ability to override parameters for that particular step, OR, make a completely new liquid “set” of liquid classes that could be used in other steps or even other protocols. This of course shouldn’t be the first tool reached for since it definitely implies advanced knowledge of how liquid parameters effect pipetting, but this is absolutely where the Prep product support team can step in and help advise for any particular pipetting that is not performing the way it should. The additional advantage of utilizing the product support team is it provides a feedback loop back to the development team for future enhancements.

16

Was there ever an update that allowed use of variables for the Prep using it’s standard software?

17

While variables have been on the radar for a while, they have not managed to make it into an official roadmap slot yet for the UI.

Are there particular items in particular steps that would prove most useful to have defined as a variable for run-time definition instead of only being available staticly at design-time in the UI? Volume has been the most consistent request, but definitely would like to hear of others that would be helpful.

On a separate note, but releated to this overall thread, the v3.3.0 software will be releasing in the next couple of weeks which includes several items previously requested in the thread. Stay tuned.

3 Likes
18

Variables in conjunction with if/then statements would be nice. I have an application with at least 4 variations that would change based on user input, volume being one. I need to make different methods to run each one currently or force the user to select from a large list of worklists. This is likely to be error prone.

19

Makes perfect sense. Variables and conditionals (and I would also add loops) definitely add a lot of flexibility to an environment and I agree asking that the right combination of method and/or worklist could be problematic from a consistency standpoint.

We’ll open the discussion back up again on how this can be best accommodated in the near future.