I think it comes down to, what are you trying to do, now and in the future? For LC/MS prep, typically that’s tube to plate transfers, barcode scanning and sample tracking. Tecan Evo has been a workhorse for that application for many years in clinical labs. Tecan Fluent will do the same thing with higher capacity - e.g. 26 tubes (16x100mm tubes) / rack vs. 16 on Evo. Hamilton can certainly do it as well. For that application, any of those vendors will get the job done.
What do you mean by “more flexible”? Tecan will allow applications like batch files or .exe files to be run from the command-line, as well as VBScripts, and has expression solving capabilities (many more expression solving options available on Fluent than on Evo).
I work with both the Hamilton and Tecans. Both can generally get the job done, so many of the differences come down to user interface, approachability of the software, historical preference and experience of the team in the lab, etc.
The Tecan EVO is the definition of a work horse. Those things can be left overnight in a hurricane and pickup the next day with minimal maintenance .
I like Hamilton’s and the software feels robust but the original Core I tech was a pain for high throughput in highly regulated environments. Every “Hamilton” house I know in the Bay Area ends up with big support teams.
I look forward to seeing some reliability numbers on the COREII “upgrades”. I know there are more “tiny” moving parts and typically the more complicated something is, the greater the chance for functional issues.
Thankfully Hamilton was kind enough to make their COREII tips backward compatible.
For more info on CORE II, check out the brochure on Hamilton’s website here. CORE II tips have been shipping since the beginning of the year and new systems are being shipped now with CORE II hardware. There are a number of improvements that will benefit customers.
From a large integrated workcells standpoint. It’s hard to look past the Hamilton/Tecan systems. It’s likely due to my historic familiarity but I tend to design systems around the Hamilton STAR line when more complex pipetting is required. For basic plate stamping/reagent additions I often go the bulk dispenser route when possible (Quick dispense cycles) or Agilent Bravos due to price point. Another neat liquid handler that I see a specialized place for is the SPT dragonfly. The large volume heads and quick dispensing speeds can be advantageous to variable plate maps with multiple reagent additions. In a system controlled by Green Button Go, the liquid handlers are simplified down to liquid handling, which many of these platforms in the correct hands can do well.
I think the biggest point when selecting a liquid handler is who is setting it up. All instruments have some limitations and I find it comes down to what limitations or features users care about the most.
I’ll second Cole’s comment about OT-2 vs. STAR/STARlet being an apples to oranges comparison.
To avoid this turning into a sales pitch, I will just say that the comparison would be between an OT-2 and a Microlab PREP system from Hamilton. (no service contracts, under 30k, user friendly software that you don’t need training on, small footprint)
Maybe @cyancey and I can do a pay-per-view cage match to settle the debate once and for all? (I’ve seen the pics of your home gym though, Cole, so I may not win…)
Happy to get more detailed and do a side-by-side, but like I said, I’m trying to avoid being “that guy” that turns an information sharing forum into a place to shout sales pitches into. my DMs are open
If we can get comparative metrics for different robots thats a win to me. I wonder if execution speed is really so important though, I doubt most users are bottlenecked by that factor. I bet downtime due to hardware failures, maintenance, calibration and reteaching positions etc are much bigger costs for users. I wonder if there is any data that supports this
It’s all about the right tool for the right job–while I’m biased towards the PREP of course, I think there are situations where the OT-2 might be a better fit for a lab. (like if you want an open software! On the PREP we’ve taken more of the Apple approach with a sealed off system–OT obviously is more of the Linux side where you can dive as deep into that code as you want. Both are great approaches, just depends on which flavor of experience you want/need. And if you want open software, the PREP is not for you)
Still, if we find a neutral ground (may I propose a local brewery?) setting up side by side and filming the whole thing could be a fun bit of professional rivalry.
I would love to see users share that data! Of course we could throw official numbers out there, but I think everyone trusts user-generated more than marketing approved
Anecdotally, I would say that the downtime discussion you brought up seems to be the bigger factor than execution speed for most labs I talk to. When you are dealing with as small a system as this discussion covers, a few seconds here or there doesn’t add up like it does on one of the big Kahunas.
Does someone worked with ABB, KUKA or something similar? I know about KUKA having its own language (KUKA Robot Language) but how does the Python support look like for these machines? I am just asking me if it would make sense to deliver a Python support for this machines. I think the whole idea around PyLabRobot is to make machines like Hamilton STAR easier to use. Is there the same potential for all this huge industry robot producer?
Actually, the goal of the project is partly to make all liquid handlers easier to use through a single API. While I have not worked with these robots personally, I think it could be a great addition. Do you have access to any?
I had the chance to see a demo at an early stage but also at a fair last year. My impression was that it is very limited in terms of flexibility (even number of samples was not adjustable then) and sensory while being significantly more expensive than e.g. opentrons. Might have changed in the meantime. Their software looked nice though
Yes it is quite rigidly locked down by the vendor and more expensive than OT-2. Samples are now adjustable. The software is really nice with clear instructions to setup and method progression inbuilt, lab scientists can pick it up easier than larger systems or OT-2. There is more flexibility in terms of pipetting given you can have 4 pipettes versus 2 on OT-2, which makes a difference for the sample preps we use it for. As it is owned by Waters they generate and test sample prep scripts for their UPLC methods etc which is helpful particularly with reagents of varying viscosity.
Did an evaluation of the Andrew+ a while back. It is extremely limited. There’s probably a place for it in certain labs. I wouldn’t call it a high-throughput instrument at all. Rather it’s more of a bridge between manual pipetting and more highly automated integrated systems. At it’s price point and with it’s software, it’s bread and butter really is for non-automation scientists to dip their toes into thinking about more highly automated workflows. It could serve as a bridge for scientists developing assays on manual to something semi-automated and lower cost without having to bug automation engineers to do it for them. Then once things are figured out, they could transfer a lot of the assay aspects to a more full-suite liquid handler. Demoed it a few times though…the system itself is very clunky. They really tried to “Apple” a liquid handler by locking all the really important power user stuff away and dumbed down the UI for non-automation people. If you lab has a dedicated automation team/person, it might be pointless to get one.
*** Disclaimer: I’m incredibly biased–I sell the PREP, which is positioned in the same market space as the Andrew+ system. I want to say this up front, because of course I’m going to like mine better! I’m not looking to bash anything. Also, I’m going to try and avoid doing a PREP vs. Andrew+ head to head comparison–there’s a time and place for that, and I’m happy to do so at that point in time. Don’t want to turn this thread/forum into a sales rep argument zone***
With that out of the way, in case it is useful, here is feedback I have heard from labs who were evaluating the Andrew+ and some other entry-level automated liquid handlers (including the PREP).
In general they were frustrated by the price point of the system combined with the lack of “deck positions” and features (like no LLD). I was told it was pretty slow comparatively as well. (They did not share timing studies with me, so I can’t speak to what that means.)
I haven’t seen a quote on it, but from what I was told, the pricing was in line with something like the PREP or some other systems like that, it just had a fraction of the flexibility/features of those other systems.
Not to say there isn’t a use case for it or that it isn’t a good system–I have not used it so I can’t speak to that, and once again, I’m not here to bash anyone.
But that is the feedback I have gotten from users who evaluated it alongside a few other systems.
I would love to hear from other people though, because I’m sure there are labs who love it!
(I have seen a couple of really cute pictures where people put faces/heads/hats on top of the robot. It’s photogenic, haha)
IMO, the PREP is a “gateway to bigger things” system. Easy to hit the ground quickly. Nice GUI. Good product support. Hamilton is a great company. Their automation field team is second to none.
I have seen labs hone in banks of OT-2s and run 40k Tube-Plate samples/day on them. They are basic, they are good. I think the leadership at OT will continue to shake things up as they continue to launch new products.
There is a warm place in my heart for STARs. They can do countless liquid handling tasks but do require a quality programmer to unleash its potential. Again, great company, great field team.
Not enough long term hands on data for me to make a comment on the newer Tecan units, but the EVOs are tried and true.
…not sure if any of that info was new or helpful. What I can add is that I have seen more sucess from the groups that take smaller bites out of automation projects at a time. Journeys are taken a step at a time. Groups that can get their robot running in days/weeks tend to grow better and faster then those biting off huge LIMS/GUI/Error Handling/Integrated/Over-Weekend Running Monsters as their first project.