What an interesting (and straight up) question.
In general, I think people are wary to answer a question that asks liquid handling manufacturer 1 âvsâ 2 because nobody wants to alienate the nice people from these companies helping us solve problems for free in this forum but at the same time balance this with constructive feedback that helps everyone.
So I will start my answer with the classic and political âit depends on your applicationâ. This by itself is a useless statement so letâs go through some examples that give it some meaning.
(The Opentrons Flex has not been released yet in the UK, so I can only talk about what I learned from talking to the fantastic sales reps, deducting from the specs sheet and my years of working with the OT-2.)
1. Throughput - Liquid handling flexibility
Case study I - cherry picking: The Flex can either have 1x 96-channel head OR 2x pipettes, in addition to what looks like a sturdy plate gripper. This means that in either configuration, if you want to cherry pick liquids from a plate, every transfer needs to run sequentially⊠this takes a lot of time! Compare this to the independently moving âchannelsâ on the STARlet you are looking at and you can see how all cherry pick source destinations that are in the same x-dimension can be picked up simultaneously, dramatically cutting your processing speed.
Case study II - plate format switching: image you move samples from 4x 24-well plates into one 96-well plate. With the Flex this would require 96-sequential single liquid transfers (because you are switching plate format, even if you had the 96-head you would need to use it as a single channel). If these samples are all unique, i.e. are not allowed to cross-contaminate, you have to get a new tip and eject in every transfer round.
Compare this to the STARlet: the (y-dimension-)independently-movable 8-channels can pick up 8x unique liquids from 2x different 24-well plates simultaneously and then transfer them all at once into the 96-well plate⊠This means you only need 12 transfer cycles (instead of 96).
2. Throughput - Deck Layout
The STARlet alone has 25 standards SLAS positions. The STARlet plus you linked has even more due to its extension. The Flex has 12 + 4 (extra) SLAS positions. Both Flex and STARlet have stacking capabilities.
3. Codeability
Here, I am biased. I taught myself lab automation using the Opentrons API documentation, and it is incredibly intuitive, elegant and very easy to upgrade. (As mentioned above, Opentrons has truly democratised lab automation, and I got the feeling it made the old bio-robotics companies finally get onto their toes again⊠a fantastic thing for costumers and science)
I assume you meant CSV file input/ouput generation: with Opentrons you interact with your robot in pure Python, one if not the most used programming language in the world (depending on who you ask). This means you can do virtually anything because you have access to the worldâs repository of Python solutions. No proprietary, click-and-drag interface controlled by a single company can ever give the same breath of functionality that a programming language can give you.
There are more reasons in this regard but I leave those for you to read in the PyHamilton and PyLabRobot papers 
4. Usability - Programming
Everything I said in the last point doesnât matter if you canât code and either donât have the time or the willingness to learn. If you cannot code then the VENUS software is probably a bit easier to start with. If you can code a little bit though then you can simply ask ChatGPT to generate Flex protocols for you, and quickly check yourself that they look correct before trying them out.
5. Usability - Calibration
Hamilton machines shine with their precision and (if maintained properly) long-term calibration. You will still have to check that your labware definitions are correct here and there but in general they require very little calibration. On the other hand, the OT-2 was a nightmare to calibrate; you had to calibrate (1) the deck, (2) each pipette, (3) the tips, and finally (4) each labware. In the end, 384-well plate handling was still too inaccurate and only when Opentrons implemented a real-time calibration I was able to reliably use them with this format. I have been told the Flex has an auto-calibrate function⊠but when I asked for more information it turned out that this only covers the deck calibration and labware still has to be calibrated manually, which can be quite time-consuming.
6. Real-Time Control - Coboting
Maybe you just want to have a lot of âwalk-away timeâ and let the robot do its thing. But maybe your application requires a centrifugation step that cannot be avoided. In such a situation you want a âcobotâ, a collaborative robot-human interaction. You can for both Flex and STARlet generate wait() or input() commands that temporarily hold the protocol but sometimes you want to add or remove some steps while you are running it.
This is possible with Opentrons because you can run your machine from a Jupyter Notebook, that means run commands one at a time, in real-time. With VENUS on the STARlet that is to my knowledge absolutely impossible.
7. Support
I am sure both companies have excellent support services (particularly if you are US-based). The question is just how much are you willing to spend. Both companies have protocol writing services, but neither has âonline protocol writing consultancy servicesâ (to my knowledge) which is something I would like to see at a lower cost point than the thousands you have to pay for a single day of an engineer to come to your lab.
8. Independence
Opentrons is absolutely amazing with its transparency. You can go to their website and find detailed information not just about their robots but also about absolutely everything they are selling, including modules and their prices. This makes it incredibly easy and fast to generate cost-utility estimates to generate the robot setup that meets your goals at your assigned budget.
I found it incredibly difficult to extract the information I needed out of Hamilton. I spent months figuring out what modules Hamilton offers themselves, which ones they support, which ones I can easily integrate myself and then asking for quotations for various modules which are all very high-end but are accordingly expensive. Hamilton sales reps have their own 3D CAD software that lets them generate robot setups for costumisation and quotations. I have been told this is not available to customers.
9. Running cost
Your main continued cost from the robot side will likely end up being tips. Opentrons tips (not necessary but I do recommend them) are pretty cheap.
Hamilton tips come in two general types: coated tips (for capacitative liquid level detection) and non-coated/clear tips (for everything not requiring cLLD). Coated tips are incredibly expensive and you cannot visually verify the behaviour of your liquids during prototyping. But they do offer capacitativeâŠ
10. Liquid level detection
The STARlet offers both capacitative as well as pressure-based LLD which is very nice and can make your liquid transfer much more reliable⊠if you donât work with low volumes. If you do then pressure-based LLD might actually suck up your liquid that you are trying to detect, and if you use capacitative LLD the charge of the tip might not dissipate adequately into the liquid due the liquidâs low volume to dissipate through/into.
The Flex has apparently pressure-based LLD, and I am curious how reliable users find it.
11. Pipetting Accuracy
Hamilton is very candid about the fact that their machines require careful adjustment of channel settings to generate accurate liquid transfers, and they sell a liquid verification kit to allow customers to build their own ideal settings (which are then captured in a âliquid classâ).
I have never heard Opentrons talk about âliquid classesâ but instead you can change all the parameters directly from the default for every liquid transfer step you perform, giving you more âin-the-momentâ control. But I am unaware of any on-deck scale or calorimetric system that would allow users to verify the pipetting accuracy with their machines.
I hope this extensive but by no means exhaustive list of pros and cons shows the nuances behind a question of the liquid handling manufacturer 1 âvsâ 2 kind.
Side note
In your question you mention the pitfalls of the Microlab Prep nicely but you donât mention that the deck space/throughput is an issue for you which makes me assume that it isnât.
If that is the case, have you considered developing a PyLabRobot (PLR) backend for the Microlab Prep yourself?
With PLR youâŠ
- would code in Python (meaning CSV, json, .txt. TSV, ⊠files are all easy do deal with),
- could customise the deck to your liking with integrations of 3rd party modules,
- tremendously increase reliability by choosing all parameters yourself,
- write protocols in PJs in bed, in a cafĂ© or in Bali, it doesnât matter, itâs just Python (no hurting arm muscles from taping onto the Prep touch screen for hours
),
all while still using the Prepâs amazing hardware (after all it is just a âSTARtinyâ in my opinion).
Additionally, I would be very interested in a Microlab Prep that can be controlled using PyLabRobot; particularly the ceiling camera for automated labware and tip usage recognition is a Prep-unique feature I have never seen on any liquid handler and could be incredibly useful for programmatic feedback control of sample processing.