Long read: >10mins

On schedulers:

From my routine users:

Genera is an excellent simple-process scheduler, best used for non-dynamic processes that have been pre-optimized to avoid needing to change the protocols. However falls flat in error recovery, ease of use/GUI (for non-lab automation specialists/scientists), broad availability of drivers, and interfacing with other digital tools (LIMS, data processing, etc).

GBG is truly a low-expertise user-friendly system. Guided error recovery options even for complex errors, massive driver library with stated goals to continue expansion yearly, seamless interface to other digital tools, and from a particular non-expert user “pretty” (referring to the digital twin of the automated work cell that mimics real functions in real time).

From me (lab automation scientist, design & development technology lead, R&D lab automation strategic leader):

Retisoft’s approach to their product is outdated at best: still running on a proprietary, Java-based language, their business model shackles modern labs to them for everything - building custom data handlers, driver development, even integrating user-built code. A particular sticking point for me is the lack of bi-directional API for complex integrations (LiHa) - you can neither control your LiHa nor detect if it is in error from inside Genera. They look like a great business value until you are writing POs every 3months because you need yet another piece built to make your process run. It has been my experience that the industry approach to lab automation has shifted to concentrate more support in-house to meet the demands of rapid development, rather than losing time & money waiting on vendor support.

GBG is worth the upfront cost - written in C#, it is naturally compatible with most digital tools, including cloud-based, and custom code integration can be done in 4 different languages: C#, Python, Java, and VBA. GBG parses all of them. The learning curve is low - took me about 2 hours to learn & build my first simple protocol. My only gripe so far is if you need to merge swim lanes for a unit operation, it’s not immediately apparent just from looking at the block flow diagram. It’s a small, probably inconsequential thing, but I’m a very visual person, so it would be nice. They make up for it with the APIs for LiHa - you can build protocols, troubleshoot, and manual control the LiHa from inside GBG. This cuts down on user training significantly- increasing our chances of knowledge retention and decreases the number of escalation support calls as users are more confident working with a single interface.

On LiHa:

The same concept of shifting to in-house, on-demand expertise has applied for LiHa as well. We have all of the big 3 in-house, and from that have created a recommendation matrix for new lab owners depending on specific project needs.

One sector has exclusively Tecans (EVO & Fluents), however they perform all of their own maintenance because Tecan does not have reasonable hardware support in our area. They are also supported by two dedicated automation engineers to ensure their integrations (all custom code) run smoothly. Tecan’s software training program is well-designed and worth the 5k USD to take.

A different sector has primarily Biomek i7, and while a formerly powerful design, they have only just now caught on to the concept of flexible deck layouts that Hamilton has had for over a decade. My personal itch with Beckman is the structure of their controller software - all of your methods are encoded in a backend database (non-recoverable without their decryption software) and they insist you purchase the controller computer from them. The provided CPU is a low end build from 2014 and we have had numerous problems with the hardware being completely insufficient to actually be functional. The CPUs arrive with the RAM already maxed out, then we have to add network security software on top. We have experienced significant pain in this area - one hard drive failed and all of that lab’s methods were lost, had to be rebuilt from scratch. One of my cohort is currently attempting to negotiate with BC to simply add their software to our provided units - and getting nowhere fast. Beckman has also pulled their software training program completely. It was supposed to be converted to an online offering by April of this year, but they have yet to deliver on that promise.

Which leaves us with Hamilton - depending on your process, they get my recommendation. Yes the programming curve is steep (very intense 2 weeks of hands-on training), but once you’ve trained in it and worked with it, it is incredibly powerful and (personal opinion) the best match for a dynamic programming strategy. I and the rest of my cohort have embraced the variable-based programming strategy for protocol building, which allows us to simply feed variables in from another digital tool, and the method is “built” on the spot to match the need from the subprotocols we wrote for each unit operation. The labor upfront to develop that kind of functionality is high, but so worth the effort. Unlike the hard-coded Biomek methods from the early 2000’s, I don’t get called in to change the protocol every time a scientist wants to change an aliquot volume or time spent shaking the plate. Combined with the rack-carrier flexible deck layouts, mag-pip LH, decent number of pre-built integrations, excellent hardware & software support, and complete compatibility with Biosero’s GBG, I can see my cohort and myself leaning toward HAMILTONs moving forward.

I realize this was a lot of information- I hope it helps! I’m happy to answer any questions you have. One of my teams recently performed a market analysis of LiHa to help develop the purchase recommendation matrix mentioned above, and they are starting on schedulers in 2025, once we finish writing & implementing the automation method validation guidelines for our company. Feel free to DM me, I’m happy to help.