Praxis: PyLabRobot in the browser, no installation required
TL;DR: You can now run PyLabRobot (PLR) logic entirely in your browser—zero installation. Try the interactive playground here. You can control instruments from the browser as you usually would in a Jupyter notebook. It all runs locally on the client-side, with PLR commands automatically re-routed through browser tools (you have to give permissions to connect, but it should prompt you!). You can also browse the PLR machine and resource catalog through the menu in the top corner, add them to the Jupyter instance, and tab completion is supported.
Key Features (v0.1alpha):
-
Interactive Playground: A full Jupyter-integrated environment with pylabrobot pre-loaded for real-time logic testing. This takes a bit to load in the environment on your first visit (and might need a refresh).
-
Hardware Discovery: Connect directly to instruments via the browser using WebAssembly routers shimming the PLR IO layers (tested with ClarioSTAR plate reader).
-
Asset Management: Manage your inventory and have it be consistently available across the app. The app largely does on the fly instantiations outside of the discovered hardware, but this functionality can be hardened for proper inventory tracking and stateful instantiation across runs.
-
Execution Monitor: Monitor your runs and view their history, with Python stdout and errors reported. Eventually, I want to have user-specified telemetry available here.
-
Simulation Mode: The most robust way to explore right now. Protocols should (and in my tests have) run to completion with reasonable parameters. Different machine frontends have different simulation backends (LiquidHandlerChatterbox, STARChatterbox,PlateReaderChatterbox, etc.) and this is handled under the hood by Praxis. If a chatterbox doesn’t exist, it just makes one on the fly that pipes the command to nowhere and pretends it succeeded.
Status & Caveats: This is an early alpha, primarily tested in Chrome from a local build. While the hardware discovery and database structure are solid, the Protocol Run remains mostly aspirational as I work through the underlying logic for protocol constraints. I have also found the jupyter kernel in the github pages website to be a bit flaky, sometimes taking a couple reloads to properly work. I only just debugged the github pages implementation but have not validated instrument control through it, but have validated simulation runs.
A bit of background:
Praxis has evolved over two years from a desire for a clear structure to data outputs and state management from reproducible protocol runs into into a WebAssembly-powered interface designed for iterative lab automation. As I progressed, I found some collaborators less familiar with coding being uncomfortable running code based commands on the robot, so having a nicer interface they could use that would feel intuitive, but still allow me the flexibility of PLR was important to me.
@rickwierenga has maintained excellent standards for PyLabRobot and the well-defined type interfaces in PLR allow Praxis to perform discovery and database generation processes and follow consistent interfacing between the browser and the hardware.
One of the features I use most often with PyLabRobot is running it interactively in Jupyter notebooks where you can define and debug individual steps and fine-tune parameters on the fly without restarting a local environment. My long-term vision is to expand the JupyterLite functionality to encompass UI based state management; one of my most common frustrations is running into a bug and having to figure out the right way to reset the state. I already have a state change tracking functionality built into the protocol run tracker. I eventually to port this into the Jupyter environment so backtracking is super easy (if it makes sense maybe this kind of state diff tracking could even be integrated directly into PLR and the error resolution work?). I also want to bridge the Jupyter environment into something you can export into protocol editor with modular composition allowing you to define arbitrary, reusable blocks (a la Blender or Unreal Engine) to build and test your workflows, with some visual grounding to help you keep track of things.
Huge thanks to Rick for the foundation of this project, for keeping the bar high on code quality, and for all his insight I’ve gleamed as I have matured as a developer. Thanks also to Stefan Golas for feedback throughout the process. The vibe at SLAS this year makes it clear that open-source is where lab automation is headed, and I hope at least some of you find this useful or fun.
I’ll be at the mixer tonight—if you’re around, let’s chat!
Docs (which I need to update…): https://maraxen.github.io/praxis/docs/getting-started/browser-mode