Some other existing options in this space (not all web based) are
- https://pymeasure.readthedocs.io/en/latest/ python Framework for running science experiments, getting hardware to go through a set of steps and plot the output. Includes a GUI.
- https://plotjuggler.io/ for really fast live time series plotting in C++/OpenGL, very fast and quick to chuck data at (just wrap it in JSON and throw over UDP) but lacks any form of input. Ideal for systems running at kHz etc, I've used it to tune motion control systems.
- https://foxglove.dev/ aimed solidly at robotics (think self driving vehicles) renders time series plots, 3D renders and point clouds, log statements etc, and supports inputs too. All written in HTML and you can write extensions for it. Unlike others, it can support a much larger data file on a server and live stream the bit you are currently viewing to your browser. Not as fast for smaller things though.
If you're going to be installing anything in adverse environments or for any period of time PLCs are the go-to for a lot of one-off solutions. Some of them get pretty spendy quickly but Automation Direct has some reasonable($100-200) PLCs[1]. I ended up automating our entire greenhouse with one including a PID based water pump to drive a bunch of different downstream outputs that worked really well.
There’s a lot of hardware projects that are arduinos, raspberry pi, and spark fun sensors when they should be PLCs and industrial sensors just because people have never been exposed to PLCs.
it's not just exposure but writing PLC is like going back to 1991, no source control, no tests, no deployment because you're writing in production. it's easier to bring cheap hardware up to par than it is to replace a vendor software.
An interesting discussion of ideas for prototyping hardware interfaces with web UIs. I appreciate the author's discussion of the design space.
Given the introduction, I'm suprised the author didn't mention another option. They talk about the limits of hand-writing the web UI for such prototypes. I wonder if components could be extracted from earlier prototypes to save time? Hand-rolling everyting would be tedious indeed, but slapping together a handful of previously-written controls would make it easier. The don't need to be slick or cover every use case, just scrappily abstracting the repeated lines of code.
Or maybe the author has already reached the limits of that strategy, hence the goal to generate a UI.
The Greybus project around UniPro interconnect has a lot of hallmarks of this all. And support is built right into the Linux kernel; peripherals just show up right away! You don't need libraries at all. https://kernel-recipes.org/en/2015/talks/an-introduction-to-...
I've previously had to justify the costs of PLC hardware for prototyping to my non-technical CEO, as well as electronics engineers who've never worked with PLCs before.
Yes, the hardware is "expensive" compared to an arduino or a RasPi. Arguably, cheap hardware quickly becomes expensive when you consider the amount of engineering time required to get something working. With a PLC, I have:
- A validated hardware AND development environment that "just works"
- Plug-and-play like capability with a huge ecosystem of instruments, motion controls, etc. etc.
- Can quickly program and test said PLC
- Can quickly develop a GUI
- Can quickly debug issues through the development environment
Obviously there's some downsides. If the sensors I need only have I2C, SPI, or similar interface, things can get a little hairy.
Resist the urge to prematurely optimize hardware based on "cost" young jedis.
I found creating a small Python webserver using Starlette plus a basic CLI using Click to be great for interacting and testing hardware. Python gives you an easy way to integrate with your actual code on the hardware using whatever interface you need with its wide support of different protocols. Click gives you a way to create a robust CLI for interacting with your Python code, and Starlette gives you a way to create a really lightweight but extensible webserver for both simple and more complex GUIs. Then, you can even add pytest on top of that for integration tests. Overall, I'd highly recommend this setup for hardware prototyping.
I've used click, and I've used argparse. In my view, a nonstandard library needs to be vastly superior to its standard equivalent to justify adding it as a dependency.
I think the biggest advantage to Click is the ability to namespace different commands to have a single entrypoint for your CLI and all your commands. For example, if you had a hardware test interface and a webserver, you could have something like following:
```
protocli hw-test i2c
protocli webserver -p 8888
```
It also does a great job generating the documentation, defining the commands is easy and robust, and it makes the CLI's more full.
I have worked with a very similar setup to prototype devices for a customer. One of the peripherals controlled was also a pump and interestingly, our interface looked almost exactly like what is being proposed here.
In terms of hardware, I can highly recommend Tinkerforge [1]. They support a wide range of sensors and actuators and can be controlled either via USB from a computer (all major platforms and many programming languages supported) or, for standalone devices, with an ESP32-based base-board called ESP32 Brick or ESP32 Ethernet Brick.
Since their products are open source (code AND schematics!) a design can be easily transferred to a custom PCB once the design is working.
Add either a web interface (native on the ESP32 or on your host computer if using a USB brick) or slap on a DearImgui frontend, and you have very powerful prototyping platform at your hands.
I'm super impressed they built a 7 person business around this concept and have been going since 2011 (all while doing their manufacturing in Germany!)
While I have frequently seen LabView used for instrument/hardware control, I admit I have never seen people use Simulink for that purpose. Is there a popular Simulink/Matlab add-on for that?
It can be indirectly. Addons exist to for instance convert the mathematical models described in Simulink to code (C, VHDL..) deployable to hardware targets. So, algorithms can be developed in simulink and then integrated into an embedded application without manual translation.
I'm curious on what the value of a frontend would actually be on this kind of project and where it is in the engineering lifecycle. I've worked in the same space on instrument control software (microfluidics, synthetic biology) and I feel like what you would gain for, as an example, putting a slider on a flow rate is of minimal use to the development of the instrument, especially in an ad-hoc iterative environment.
The engineer who is writing this software and building the system in tandem will be able to express most of their experimental/engineering needs via a CLI tool and something that visualizes instrument state and sensor readings. For example, I've gotten quite a bit of mileage out of throwing Grafana as a graphing interface and then using ipython to essentially have a REPL to control logical subsystems, such as a pump or a motor. This allows you to interrogate the empirical limits of your system without having to spend time centering divs or caring about button placement.
This is only true if the engineer is the intended end user of the system. As you scale out and include other disciplines in the project you do have to consider the user interface as the window into the instrument.
I've played with the automatic GUI element generation from parsing the underlying control code before. I think its a fun bit of meta problem solving, but I've always ended up in a corner that requires some sort of bespoke tool or widget to solve a tricky problem arising from the scientific domain. I think you might be fine if all you are doing is controlling a syringe pump or similar, but as the experimental needs become complicated you'll end up re-writing the control interface as a deliberate experience and toolbox.
I've gone back and forth on this. I'm involved in very early stage development of sensors and instrumentation systems. If anything I create threatens to end up in a real product, there's an entire department of coders who figure out the user-facing side of things.
What I find useful is real-time displays, when I'm still at the stage of manually adjusting and optimizing things, and sometimes a few controls so I don't need three hands in the lab. But on the other hand, dialog after dialog of settings can easily be managed instead with a human readable text file.
Tkinter and Matplotlib actually work well enough for my use. I don't need to make anything look as slick as a management dashboard, or completely user-proof. I've developed a great appreciation for the time and effort (i.e., cost) that go into creating fabulous GUIs. Most makers of sensors and controls who send out a "demo" or "setup" app never get to that level.
In my experience, having a quick and dirty HMI/GUI is a must have during commissioning (initial start-up, tuning, etc.), debugging, and shut down. In all of the industrial automation and building automation projects I've been involved in, there's always been a set of commissioning HMI/GUI which is different to the HMI/GUI used in production.
The other thing that makes PLCs great is that they can be programmed in ladder logic, more or less visually, by technicians instead of professional programmers. The heavy real time lifting is done for you - the “language” is a descendant of notation for relay racks.
Oddly enough, PLCs are another example of a dataflow programming being intuitive for regular people -- the others being LabVIEW and Excel. Of course I'm exaggerating a bit by putting all 3 of these tools into a single category, but I also don't think it's outrageous to make this claim.
Indeed, PLC's originated with GM calling for a programmable controller that could be used without having to completely re-train their large workforce of control engineers and technicians, who were already familiar with relays, mechanical timers, switches, and so forth.
It's funny, I spent a good long while in gamedev with various visual tools(UE3 Kismet[1], node/UI editors in Maya/MAX, etc). The parallels between PLC workflow and those are uncanny.
Might be one of the few industries where I've seen visual hot-code reloading on-the-fly in production scenarios used at scale. The visual debugging of ladder is really similar to debugging tools we had, heck FBD[2] comes really close as well. Kind of an interesting covergent evolution of two different domains coming to very similar tools.
Working on a similar project[1] that its similar to a PLC but its low power, with a solar panel and it has plug and play modules (see link with animation). We are trialling it now with a few customers and planning to open-source it. Trying to get the OTA working and the manufacturing sorted..
They're using Rust, which is a great language for this sort if hardware: It can run on hardware itself, and can make responsive, PC applications to interface with it. Perfect excuse not to use a web UI, but this article is demoing one anyway.
EGUI is ideal for this sort of thing. Can make hardware interfaces (eg using USB as a serial port or HID device) into a fast GUI program. Add WGPU if you need anything 3d rendered.
- https://pymeasure.readthedocs.io/en/latest/ python Framework for running science experiments, getting hardware to go through a set of steps and plot the output. Includes a GUI.
- https://plotjuggler.io/ for really fast live time series plotting in C++/OpenGL, very fast and quick to chuck data at (just wrap it in JSON and throw over UDP) but lacks any form of input. Ideal for systems running at kHz etc, I've used it to tune motion control systems.
- https://foxglove.dev/ aimed solidly at robotics (think self driving vehicles) renders time series plots, 3D renders and point clouds, log statements etc, and supports inputs too. All written in HTML and you can write extensions for it. Unlike others, it can support a much larger data file on a server and live stream the bit you are currently viewing to your browser. Not as fast for smaller things though.