Web server architecture
In this robot control architecture using Flask, a lightweight web application framework for Python, the source SDL control module is dynamically loaded into the system through global configuration upon launching the server, allowing the backend to access robot control methods (Fig. 1). Clients interact with the robot through HyperText Transfer Protocol (HTTP) requests that specify the instance through the Uniform Resource Locator (URL) and include a POST payload with task details (see Supplementary Information, S1.1 for function calling post request). Upon receiving the request, Flask routes it to the backend, where the loaded SDL control module is accessed to execute the corresponding function (example of method execution in backend in Supplementary Information, S1.2). Once the task is completed, the server sends a response back to the client, returning the result and a server status update. The web server allows remote SDL control from other devices in the network. Additionally, a socket connection is used to stream real-time logs to the client, allowing for continuous monitoring of the SDL’s activities during task execution (Fig. 1).
Python client
To facilitate a more direct control for clients over SDL and abstract the complexity of HTTP communication, the ivoryOS can automatically generate Python Application Programming Interface (API) classes for all available SDL control methods by requesting the snapshot from the backend (Fig. 1 – Python API frontend; Supplementary Information, section 2). These generated classes allow developers to programmatically interface with the robot using Python, just like they would with a local SDL instance. Each generated Python class will act as a proxy that hides the underlying HTTP communication. When a method is called, the class sends the appropriate HTTP request to the server (via post) with the necessary function name and arguments. The recreated Python API mirrors the original functions from the SDL control script, allowing developers to continue utilizing their existing (source SDL control) Python code to interact with the robot.
SDL direct control interface
The displayed web forms within the direct control interface show all available methods of an SDL or laboratory equipment (Fig. 2a). Users can navigate through available methods and interact with the SDL by inputting required parameters. The control interface can be customized and reorganized through drag-and-drop interactions to suit frequent usage and visibility preferences. Such flexibility enhances the usability and adaptability of the interface across various SDL frameworks or individual laboratory equipment APIs, 28–30 permitting a plug-and-play GUI for prototyping hardware before the development of a dedicated GUI.
Workflow design
To facilitate experimental design through visual programming, the interactive web forms ((Fig. 1 - backend) are enhanced with a save field for storing function return values. Users can start by browsing systematic or logic operations or available SDL-specific instances (Fig. 2b; step 1). Upon entering function parameters in the web form and clicking “Add” (step 2 and 3), the defined workflow task is scripted into a structured JavaScript Object Notation (JSON) format (Supplementary Information, section 3). This task is then visually represented on the design canvas, where users can interactively reorder tasks, remove unnecessary steps, and adjust function parameters by clicking the corresponding entries (step 4). Once the design is complete, users can click the “Compile and Run” button to validate their design and proceed to the workflow execution page (step 5).
To enhance experimental design intuitiveness, each SDL device instance integrates a text-to-code option that attempts to translate natural language task descriptions into SDL code (Fig. 2b; step 6). Our previous work successfully translated literature into machine-executable scripts using large language models like GPT-4.31 The translation is achieved through strategic prompting by giving sample code and instructions that maps chemistry tasks description to machine operations. In the context of flexible SDLs, where device functionalities are highly adaptable and lack strict operation mapping rules, we adapt this approach by appending the SDL snapshot instead of defined mapping rules. An example of the expected JSON format used for visual workflow programming is also attached to the prompt, ensuring successful display on the design canvas. Additionally, a post-processing step validates the scripted functions to further guarantee the alignment with the module capabilities. The full prompt using the example SDL is in Supplementary Information, section 4.
The database interface, as shown in Fig. 2c, is implemented using Flask-SQLAlchemy to facilitate comprehensive management of experimental workflows within the system. This interface supports functionalities for saving, organizing, and loading workflows into the design interface from the database. Users can edit existing non-protected workflows, with changes being saved to the same or new workflows. Additionally, the saved SDL snapshot allows users to design and manage workflows without the need for direct connection to lab hardware.
Experimental phases and parameters
Each workflow consists of three experimental phases: a preparation phase for preliminary steps, like purging solvent lines, a main experimental phase involving processes such mixing, heating, purification etc., and a cleanup phase to reset the platform post-experiment. Users can change between editing phases using the tabs on the top of the workflow canvas (Fig. 2b; step 7). While the preparation and cleanup phases execute once with only constant parameters, the main experimental phase is repeatable and supports dynamic parameters (Fig. 3a). The use of dynamic parameters, in contrast to a constant value, can change during execution, allowing different iterations without modifying the workflow. In the workflow design interface, users can define a configurable (dynamic) parameter by employing the “#” notation followed by the parameter name (e.g., “#amount” instead of “5” in Fig. 2b; step 2). This feature allows for flexible iterations with various execution options, such as parameter entries or an optimizer that adaptively suggests parameters (Fig. 3b, see Workflow execution section).
Workflow execution
After a successful compilation of a workflow, three Python functions, representing the preparation, experimentation and clean up phases of the current design, will be generated (Supplementary Information, section 5). The script is available to download for usage without using ivoryOS web interface. Over the execution interface, the available execution options will be available depending on the parameter type and the presence of output values (Fig. 3b). The repeat option is designed for workflows with constant parameters, allowing either a single iteration or repeated iterations (Fig. 3c). For configurable iterations, defined parameter names and their respective data types are used to generate an empty configuration CSV file (Fig. 3d). Users can populate this CSV file with parameter values for each iteration and then upload it back into the system. For designs with fewer than six parameters, there is also online form option for quick iteration design (Fig. 3e). Additionally, for flexible workflows that also yield at least one numerical output, the Bayesian Optimization option with Ax platform32 becomes available, enabling adaptive exploration of the experimental space for optimized results (Fig. 3f). In this interface, all defined parameters and output values will be listed in the Parameters and Objectives sections respectively. Note that only numeric outputs can be used as optimization objectives; non-numeric outputs should have their optimization option set to “none”. For all workflows that generate output values, a CSV file will be created to record the data, which will be available for download.
PurPOSE platform integration
Although the SDL development and frameworks exhibit variations across institutions and developers, Fig. 4 showcases a typical SDL development structure using the Purification Platform Optimizing Solubility based Experimentation (PurPOSE) platform developed in the Hein Group.33 The development process begins with core hardware components and evolving into multiple user functions that utilize this hardware synergistically. For instance, the user function “add solid” necessitates the coordinated operation of an automated balance, a capping mechanism, and a robotic arm for vessel translocation.
As developers transition from controlling individual hardware components to designing higher-level user functions, custom layers can be added to manage various levels of robotic control. These layers may handle low-level tasks such as vessel transportation or coordinating the automated balance with the robotic arm. The experiments level (as shown in Fig. 4) is typically constructed using user functions as building blocks along with decision-making steps, resulting in ‘ready-to-execute’ scripts. A typical application of the ivoryOS is its interface with experiment conditions inputs during (high-throughput) executions, allowing users to browse available experiments and configure iteration parameters. To support workflow building from user functions simultaneously, developers can define which operations are accessible by importing instances from different control levels. By integrating ivoryOS into the PurPOSE, we provide access to both hardware handling functions and experimental operations, enabling low-level control, workflow design as well as experimental execution. A demonstration, along with a code example and a video, is available in Supplementary Information, section 6.