Robotic Scripting: GUI vs Coding
Intro:
Liquid handlers alone aren’t enough to automate your experimental workflows. They require instructions in order to execute a protocol. These instructions can be given two ways: using proprietary control software packaged in a GUI and using a programming language, like Python. In this post, I’ll talk about scripting a liquid handler with a GUI, scripting with Python, and considerations for both in the lab; additionally, I’ll talk about OpentronsAi and how it translates a written prompt into Python that can be used to script your Opentrons robot.
Scripting with a GUI
GUI stands for graphical user interface. They are usually advertised as code-agnostic, user-friendly software that enables control of your liquid handler. The major liquid handling platforms, think Agilent Bravo, Tecan Fluent, and Hamilton STAR, all have their own proprietary software that works best with their proprietary hardware. The software for the aforementioned liquid handlers are VWorks, FluentControl, and Venus, respectively. This allows for faster method development because no integration is required.
This doesn’t mean that integration isn’t possible. Through my experience, Hamilton and Tecan offer support to integrate third party instruments with their liquid handling platforms. This includes integrations with their control software. A common integration I see is with a Liconic automated incubator for cell culture workflows.
There is third party control software available that claims to address bottlenecks seen with other GUIs. Two that come to mind are Spaero Bio and Synthace. Spaero Bio aims to save time scripting, validating, and debugging a protocol with its “self-healing” capabilities. Synthace offers a DOE function and data aggregation capabilities, perfect for integrated informatics workflows.
A platform like the Automata LINQ has it’s own GUI and a bench equipped with a robotic arm that enables integration with many instruments. In addition to the robotic arm, the LINQ Bench also comes with the Bridge or Maglev attachments to move plates across the bench. LINQ canvas is their GUI that advertises simple workflow creation. They also offer a developer experience for users that want to use code for robotic scripting instead of a GUI. I’ll get into that more a little later. Try out their demo to get an idea of how easy it can be.
GUIs are marketed as something anyone can pick up and start using. You’re still using coding principles like programming loops, if/then statements, writing functions, parsing CSVs, etc, but the GUI uses interactive graphics to build a protocol. In Tecan’s FluentControl, you can drag and drop digital labware on the simulated Fluent deck. You build your protocol by dragging and dropping specific functions in a sequence, filling in the variables, and executing it. While a software like this does use programming principles to build a protocol, it can also have its own syntax. This brings into question standardization of scripting in lab automation. Before I dissect that statement, let’s take a look at using a programming language to script a robot.
Scripting with Code
I briefly introduced the pylabrobot library, which is a Python library that allows a user to use Python to script their liquid handler. Recall that Python is a programming language used to give instructions to a computer's processor to perform specific actions. To control a liquid handler from a coding environment like VS Code or Jupyter Notebook, you need a way to communicate with the hardware. This is where APIs and backends come in.
API stands for Application Programming Interface. APIs define how software components exchange data and functionality to perform various operations. They specify how data can be requested, accessed, and updated between applications. Many liquid handling robots have their own APIs, or communication interfaces, that allow software to control them. In the context of pylabrobot, the library uses "backends" to handle communication with different liquid handlers. The backend often uses the robot's API to send instructions to the hardware. The backend acts as a translator, taking pylabrobot's general commands and converting them into the specific calls and requests that the robot's API or control system requires to execute those actions. The pylabrobot library contains different backends for different liquid handlers ready for your use.
Python isn’t the only language that can be used to script robots. Hamilton has its own language, HSL, which is C++ based. For some people, the GUIs can be clunky, and having a standardized language allows for easier troubleshooting and debugging. Additionally, using code to script a robotic protocol allows for more finite control of your robot for things like optimizing the path a plate travels across the deck. For large runs, shortening the path that your labware travels shortens protocol time overall. More finite control also allows for integration with different instruments.
Like I had mentioned before, coding can offer more precise control over your robot compared to a GUI. This can be useful for early stage research where protocols need to be adapted quickly based on preliminary results. Coding also allows for version control, which can de-clutter your protocol library. Instead of making a tweak to a protocol and saving it under a whole new name as you would in a GUI, just change the version number and add a comment in your script detailing the change.
A fully automated system cannot exist without code. It’s one thing to use a GUI to program a teaching point for a third party instrument, but in order to control that third party instrument with your liquid handler’s control software, an integration needs to be built so the software can access the third party’s API.
The same is true when integrating software. In an integration I helped build, we needed to get data from our plate reader into our data management system analyzed and visualized. We hired software engineers to build that integration.
With wider usage of AI comes more accessibility to coding. Combined with resources provided by the coding community, like documentation, message boards, and repositories, scientists can use code to program their robots if need be. Just be sure that using code doesn’t invalidate any service agreement you may have with a vendor. For example, there may be conditions preventing the use of libraries like pylabrobot or pyhamilton in your service contract, but using HSL, Hamilton’s proprietary coding language, is a way to harness the precise control of coding while operating within the terms of your service agreement. Be sure to talk to the vendor to see what’s possible.
Tradeoffs
When considering which method to use for scripting your robots, take into consideration what you’re planning to use the robot for and the personnel you have in the lab. If you have just one robot or a line of robots from the same vendor, and you have limited coding experience in your lab, scripting on a GUI is probably the way to go. The scale of support you can receive from a vendor varies with how much help you’ll need, and this can get pricey.
Having the vendor write all of your scripts and train scientists to run them can add a huge expense to an already expensive system even with a service contract. Some vendors also sell training courses to get a scientist more independent on scripting the robot themselves. I took a training course for a robotic platform, and it ran my company about $5,000.00, and this was for remote training over zoom. This was only the intermediate training course too. Having an on-site expert can save a ton of money on service calls for your liquid handler, but you’ll likely spend tens of thousands of dollars getting them trained. If this investment is within your budget, this is definitely a route to consider. It’s also a highly employable skill to be competent with a GUI since liquid handlers like the Tecan Fluent and Hamilton STAR are prevalent in the industry.
One thing to consider with a GUI is that the syntax, or the “grammar” of the scripting language, is proprietary and might lack the amount of open-source support you get with a programming language. While there are forums like labautomation.io to discuss specific issues with GUIs, this is a far cry from the development community you see with traditional programming languages. If you’re working outside of business hours or have an immediate need for help, the vendor will not always be available to get your script working. I remember having an issue with my script because there was the mu symbol and the micro symbol, which both look like µ, but I used the mu symbol instead of the micro symbol and my protocol would not run. There was no error message to let me know that was the case, and it took the vendor telling us about it to get it resolved.
GUIs have come a long way since I started using them years ago. They have streamlined more complex scripts with pre-built modules and some vendors integrate instruments that can be controlled by the platform's control software. GUIs often use drag and drop interfaces that are more intuitive to scientists than a line of code. Imagine dragging a virtual plate onto a virtual deck and those changes being recorded on a robot. You can click on a well and tell the robot to transfer its contents into another plate by selecting an option in a dropdown menu. At the end of the day, GUIs are more user friendly, but it's important to consider using code over a GUI if you want more flexibility, complexity, and better debugging.
Using code to control your liquid handler requires knowledge of programming languages. Hiring a career coder isn’t cheap, but it’s another investment to consider if your protocols operate outside of the limitations of a GUI. But, as I had mentioned before, coding has become more accessible with the advent of AI tools like ChatGPT and Google Gemini. I set up my first coding environment and wrote my first macro from scratch using my company’s internal AI tool. Not to mention the code repositories that are available to you in places like GitHub. You can get started today and have a simple script ready to use in a few hours! Here are some advantages of programming a robot with code:
Program dynamic protocols: For example, a pipetting method that can adjust pipetting volumes based on real-time sensor readings.
Ultra-high throughput protocols: Optimizing plate paths in an ultra high throughput screen, like screening tens of thousands or hundreds of thousands of compounds, can save a ton of time and get data out faster.
Integration: There is no GUI out there that can build integrations for you. Code is required to incorporate other hardware and software tools into your automation workflow.
Documentation: Version control allows you to track changes in your script more closely.
Data analysis: Perform complex calculations in your protocol and perform experiments based on that calculation. Ideal for DOE(but look into Synthace’s software for a GUI-based solution to DOE)
I want to emphasize that while I do have a lot of experience in the automation space, I don’t have experience or knowledge of every GUI that exists. It’s likely that GUIs are addressing their own limitations, so it’s important to take that into consideration also.
Opentrons AI
I wanted to talk briefly about an AI tool that exists in a niche that I didn’t cover above. Opentrons AI translates your text into a python script that can be run on an Opentrons robot. Opentrons is known for its flexibility to use their GUI or code to control their robots. On top of that, their code is designed to be accessible to anyone with basic knowledge of Python and wet-lab skills.
I got to demo OpentronsAI at SLAS. You can access a demo yourself here. Let’s break down how this works. You fill out a form to generate the prompt. Here’s what mine looked like:
Here’s that prompt translated into code by the AI:
And here’s an explanation of what the code is doing:
The important step I want to break down is what a loop looks like:
For i in range(7):
source_row = plate.rows()[i]
dest_row = plate.rows()[i+1]
In this code ‘i’ is a variable that represents a row. For i in range(7) translates to ‘for a row in the range of 7 possible rows’. This way, your loop doesn’t include rows beyond the scope of the plate. The source row is the row we are aspirating liquid from, in each loop that’ll change as we iterate, or move to the next step. i+1 is the row that we are dispensing to. Whenever a loop moves to its next iteration, the value of i (row we are aspirating from) changes. A loop is an easier way to write out this code as opposed to writing a new line for each aspirate, dispense, and mix step. This keeps the code concise and easier to read.
A good learning exercise is to copy and paste this code into an AI tool to break down each step for you. It can help you get a grasp on Python syntax and help you modify your own protocols.
Conclusion
Choosing to use a GUI or code to script your robots is just another example of how lab automation is not a one-size-fits-all solution. You need to take into account the resources available to you and make a call for what is most accessible and most affordable. Hopefully this call is easier to make now that I’ve shown you the advantages of using a GUI or code, the tradeoffs between them, and an example of a cool AI tool that bridges the gap between human speech and a Python script.