User feedback and reasons to use PyLabRobot

[lukas.bromig]

Hi all,
I’m curious to understand all the different reasons why people are getting more interested in and start using projects like PyLabRobot and moving away from vendor software like Venus and Fluent Control.

1. What made you switch from the vendor software to a code-first approach?
2. What is your use-case and would it have been possible to achieve your goal with the vendor software?
3. What is the most important feature to you of e.g. PyLabRobot or other code-first libraries for liquid handler control?
4. What are the downsides of using these code libraries? Do have issues with management, robustness, or something similar?

I’m an advocate for open interfaces and standards and I’m in touch with hardware vendors on these topics on a daily basis. The time feels right to break down these barriers in the lab space. Really looking forward to your comments and thoughts!

[rickwierenga]

I’m obviously biased, but I’ll share my motivation for working on this project:

• Interactive development: iteration time is key, and by sending atomic firmware commands it becomes possible to very quickly iterate on specific parts of a method in a Jupyter Notebook. This is a lot better than having to run methods end-to-end, as is the case with most vendor software.
• Hackable: related, everything in PLR is open source so it’s easy to hack on.
• More control: the Python interpreter is generally more flexible than a vendor ‘program executor’. This is particularly important when your method is not completely known when you hit “start”, which is doing almost anything besides simply automating a fixed protocol. I don’t see how you’d replicate some PLR demos in any other software (Two PyLabRobot Demos, PyLabRobot Demo: Game of Life)
• Not having to use Windows
• Universal control: the universal interface stimulates reproducibility of methods
• Shareable methods: you can source control/fork Python methods a lot easier than proprietary file formats. Also good for reproducibility.
• Access to the Python eco system

As for downsides:

• PyLabRobot is a community developed project and not backed by any manufacturer (perhaps also an upside). This means there may be more errors, particularly at this stage. Over time, it is possible PLR actually becomes more robust because users can contribute bug fixes without having to go through a manufacturer. Our development speed is higher.
• No certification/regulation: I’m not sure this software can be used in hospitals or other highly regulated environments.
• All external hardware needs to be integrated: whereas Hamilton is great for having many device integrations, they all rely on VENUS and cannot be used in PLR (PyHamilton could be a great compromise, it essentially provides a Python interface to VENUS). This means that more work needs to be done before interfacing with a device that is not integrated yet, but at the same time we get to rethink a lot and write the best interface possible.

[BirdBare]

1. What made you switch from the vendor software to a code-first approach?
   It’s easier to hire computer scientists fluent in mainstream languages like C# and Python and teach them basic liquid handling thought processes required for method development. I’ve found that lab scientists write really terrible programs in all languages and vendor software is no exception. Additionally, because vendor software is often limited you end up writing hacks or workarounds that would not be needed in a mainstream language.

2. What is your use-case and would it have been possible to achieve your goal with the vendor software?
   We have offloaded all ‘simple’ method writing to lab scientists within reason. Our group focuses on new vendor technologies or integration issues rather than the minutiae of changing, for example, a series of steps associated with a quench or magnetic bead elution. Thus we set out to create a visual programming interface that abstracts away the low level details. It: combines our collective automation knowledge to seamlessly handle solutions of differing compositions, efficiency handles the equilibration of temperature control devices, and guides the users to perform optimization of more complex integrations like vacuums or centrifuges, and more. No we could not have done this in vendor software.

3. What is the most important feature to you of e.g. PyLabRobot or other code-first libraries for liquid handler control?
   It needs to be usable by lab scientists who have no interest in programming. Full stop. Edit: sorry I missed code-first. Honestly full control of the device in a similar manner to vendor software. I like that I can program with the same commands as vendor software but use Python to do it and if I have questions I can refer back to vendor help documents. I wouldn’t want to use something that changes the underlying interaction with the system. For this reason I like PyHamilton much more than PyLabRobot. Thus, we rewrote PyHamilton internally as PytomatedLiquidHandling to incorporate improved abstraction, typing, and command execution.

4. What are the downsides of using these code libraries? Do have issues with management, robustness, or something similar?
   I have only found increases in efficiency and quality of life in all aspects of automation programming.

[CamilloMoschner]

1. What made you switch from the vendor software to a code-first approach?
   So many reasons, some…
   a.) a return button ! - I don’t understand how customers are just okay that some big liquid handler manufacturers do not offer the ability to take one step back in their automation design… every automation run requires testing, how can one test systematically without a timeline of changes made?
   b.) version control and management across multiple liquid handlers across an entire company (closely related to the increased robustness of methods mentioned above); PyLabRobot is “just Python”, every modern coding practice standard is now useable for automation. Comparing this to the use of outdated file formats that cannot (easily) be git controlled and are a nightmare to manage across different teams, it is an easy decision.
   c) automated automation design - everyone just talks about physical automation and forgets that you can also automate the design of the physical automation… with Python or pen and paper. I have never seen a vendor ever address design questions, and tbf with their varied customer needs that is constantly changing. But Python offers the ability to solve the design and instantly execute it. I firmly believe that almost all lab tasks are fundamentally spatial programming and combinatorics problems, for both programming solutions already exist, why not use them and…
   d) Utilise the world’s repository of prior coding solutions - Python - when dealing with a new lab task.
   e) Reliance on manufacturer support (though the application scientists I worked with from different companies were all amazing, it is too slow) and
   f) Cost
   g) update speed… and cost - the only automation company that leads the way here, as far as I am aware, is Opentrons. They listen to their customers and send firmware and software updates out in regular intervals without any cost. Otherwise most companies ask you to pay extra for every new version. (They also offer both GUI and Python based coding, incl. Jupyter Notebook-based control)
   h) development speed - thanks to @rickwierenga and some other amazing people here on the forum, PyLabRobot is developing at breakneck speed, what is an issue one day might literally be solved on the next day.
   i) capabilities - there are so many needed functions that big manufacturer software does not provide, e.g. aspirate with 2 tips from a 50 ml Falcon tube (already built into PLR); transport [list of source wells] - [list of different volumes] - [list of destination wells] in a throughput adaptive way (adapting to all 3 lists), e.g. a normalisations (took me 30 min to figure out in PLR). I know submethod solutions exist to some of these problems but they usually require you to contact the company, get a response, back and forth (aggravated by the fact that oftentimes companies don’t even track their own submethods). This takes a long time and then maybe only get half a solution. Why not just use natively more powerful software? (though to be precise, Python is not a software but a language and therefore is, by definition, more powerful. So I’m not sure whether this comparison is really fair)
   j) machine integration & control; though atm big companies’ software provides overall more integration you will always be limited to the companies’ support; also, I like my robot to email me when its starting the last step of a run - easy with Python/PLR
   k) an AI-assistance future.
   l) opportunity to develop not just automated runs but autonomous runs.
   m) using Linux-based OSs and the simplicity they provide.
   n) empowering users through cross-platform protocols and sharing - PLR allows one to name labware. This means protocols can easily be written in a way that allows one to use different robots for the same protocol, making one less dependent on any specific machine. Instead one can quickly test out different robots and choose the one they like the most. Also sharing protocols can be done by simply sharing text (much simpler than old data formats that cannot even be emailed without corrupting the file).
   Frankly, going through the long list of reasons to adapt code-based automation, one has to ask why big companies haven’t written their own Python API in parallel to their GUI (which is possible as demonstrated by the underdog, Opentrons)…

2. What is your use-case and would it have been possible to achieve your goal with the vendor software?
   Varied use cases across everything imaginable in biotech. No, I would not be able to achieve my goals with vendor software. The manual interfaces all require manual automation design, that simply takes too much time and throughput adaptiveness with worklists has serious limitations.

3. What is the most important feature to you of e.g. PyLabRobot or other code-first libraries for liquid handler control?
   Version control compatible

4. What are the downsides of using these code libraries? Do have issues with management, robustness, or something similar?
   a) Yes, you have to know how to code (even if just a little bit). This means training users can be more complicated (I feel fortunate that I work at a company that encourages new tech and most of my non-coding peers are eager to learn - very different from academic environments I came across).
   b) PLR is in development. That is a con and a pro at the same time. In regards to the downsides, it means that you might update your repository and suddenly things that have worked don’t anymore, then you have to hunt down the reasons why. People who don’t like solving problems might not be okay with this. But as time progresses, the codebase is destined to become more stable - much better than before. Amazing software is imo built through iteration and feedback, and PLR is a wonderful example

[luisvillaautomata]

Slightly different take, not coming from an R&D lab…

1. What made you switch from the vendor software to a code-first approach?

Depends on the LH, but you CAN kind of build a code first approach WITH vendor software. It’s just painful. The reasons for making a change are many but for me it’s primarily because vendor software tends to not be as iterative or as fast as we need them to be. In addition, once you have a proper IDE environment it’s tough to move on from that experience (intellisense & unit testing.) It’s just a vastly superior way to build consistently across teams, sites and formats. With larger teams across multiple sites with hundreds of protocols… you can manage fleets with ease if you have code-first setups.

I’m also a big believer that a clean programmatic architecture democratizes the software/hardware experience so that anyone can play ball. And if you’re heavy on SW background, you also now have the advantage of utilizing Docker & cloud services to further integrate your lab into an existing tech stack.

2. What is your use-case and would it have been possible to achieve your goal with the vendor software?

I prefer to treat the LH like a microservice. I can somewhat achieve these goals with vendor software but it’s painful. People do build architectures from vendor software that is 1:1 with some or many SWE principles but it’s not as easy to do it.

On that note, will it be SiLA2, OPC-UA, PyLabRobot or a combo? Who knows! However when a shift comes (and it will), I’ll be able to easily adopt changes with a phase appropriate approach for any regulated environment. As more LH & software vendors align, I’ll be able to transition to the communication protocols that best utilize these interfaces. And then eventually purely programmatic code bases can be adopted once they’ve been thoroughly vetted.

A surprising number of lab auto engineers actually aren’t aware that Tecan has had a SiLA2 server for the Fluent for a long time (C# or Python). Tecan seems all in on supporting these initiatives including PyLabRobot (hence the EVO) so I’m optimistic that at least one major liquid handler company is seriously looking at PyLabRobot or SiLA2 or OPC-UA. And so I could in theory use a Tecan Fluent with their SiLA2 server to programmatically run protocols and build basic protocols. I’m sure you’ve seen the pro’s & con’s of this Lukas.

3. What is the most important feature to you of e.g. PyLabRobot or other code-first libraries for liquid handler control?

Flexibility. Treat your lab auto stack like a proper tech stack. Build whatever UI or UX experience you desire, integrate and spin up a webpage in an hour or less with your favorite cloud service. Plus you have the benefit of every other library/Nuget package that is out there. If you’re a vendor. you don’t need to waste resources building libraries or drivers for services that are freely available. You can just focus on the core product. Potentially better DevOPs & security.

4. What are the downsides of using these code libraries? Do have issues with management, robustness, or something similar?

Lack of vendor support. Also biotech companies tend to add lab automation at the very end of their commercial or discovery process so this means that building out a good code library may still be a disaster. Maybe the upfront process can take a little longer while you build out protocols. Slightly less of a concern could be hardware damage if you don’t know what you’re doing and general fear from leadership about directly controlling firmware in this way. Lack of audit trails and other basic requirements for compliance.

With that said, I prefer code-first approaches right now because the current development experience is terrible. However it’s possible that in the future we’ll be able to link processes together in a much more seamless way with smarter vendor software that “discovers” hardware and makes the low code/no code experience truly seamless and crash free. Better simulation with digital twins is also on the horizon and I’m optimistic about spatial computing, I think this will allow us to control our liquid handlers as if they were extensions of our bodies. (See the hackathon.)

Finally there’s a lot of bespoke equipment & solutions being built which poses interesting questions. If you are no longer optimizing for humans, you can build some pretty incredible things. As AI & autonomous robots become more common, I envision that hardware, software, protocols, & assays will further evolve. Maybe in the future all assay development & discovery will happen on a device first instead of manually in a hood. To utilize these new modalities, code-first is critical. Period.

One day my hardware will come with SiLA2 or OPC-UA servers so vendors can keep their hardware as safe as possible and I can build without worrying about integration layers. That’s the dream.

[lukas.bromig]

Thank you all so much for the replies! This is amazing. I’m currently trying to shed some light on the vendor perspective here as well. I’ll give an update once I have more info there!