Are there any off the shelf industrial controllers/PLCs for which there is a rust compiler target?
What would a workflow with Rust look like in the context of industrial controllers?
Would it be possible to to write code in any editor, compile it and then flash it to a controller and have it work? Is this something people are working toward?
What's the closest thing we have right now to just writing code, compiling it and using it on industrial grade devices?
There was some discussion of this about a year ago:
One of the participants, @Michael-F-Bryan, also has a slightly newer project than the one posted in that thread:
Rust, via its LLVM backend, can compile for the MSP430, which is found in some industrial controllers.
Not that I know of. I work in the CNC industry and when looking at alternate controllers we didn't find anything mentioning Rust.
Most PLCs I've seen will be based on the IEC 61131 family of programming languages (ladder logic diagrams, and structured text, etc.).
I've also run across one or two motion controllers where they've created their own custom DSL that gets compiled on the controller, often with support for interoperating with the IEC 61131 languages.
As far as I know... Write code for a normal microcontroller (e.g. STM32, probably using an RTOS to make things easier) and build the code abstracting over and interacting with hardware yourself 
Something you've got to keep in mind is that the entire industrial motion control industry (including PLCs, CNC, etc.) tends to be very slow to adopt new technologies.
From my experience with customers and vendors, a lot of people are of the opinion that "If it's not broke, don't fix it" and will often run the same machine without any changes other than replacing mechanical parts (e.g. worn bearings) for decades. Unlike a lot of things that exist purely in the digital world (e.g. Amazon, Paypal, high-frequency trading, etc), it's quite hard for improved technology to obtain the order-of-magnitude productivity gains that would justify sinking money into R&D and re-training users.
There's also a lot of vendor lock-in, which removes a lot of the pressure for vendors to continually improve (you won't see an arms race between Siemens and Beckhoff, for example).
While I may sound quite pessimistic, I can see a real niche for an alternative industrial motion controller that is based on Rust. I'm just trying to give you a bit of background info so you know how the industry got to where it is, and what is influencing business decisions.
A lot of motion controller implementations I've seen are pretty average and a Rust implementation could have tangible quality benefits, particularly around API design and fault tolerance, due to how the language wants you to write code (borrow checker means your ownership story needs to be sane, Result<T, E> means all errors are dealt with in some way, etc.).
It would also let developers of larger, more complex motion control projects have a solid platform to build on, instead of going with sub-standard motion control platforms or rolling your own with a microcontroller from scratch.
Thanks for that great info @Michael-F-Bryan.
It surprises me that there is no way to write your own code for a controller. I have no experience with industrial controls, but it is something I'm really interested in.
I know that PLC manufacturers have their own software for programming or provide a runtime for something like CodeSys, but at the end of the day wouldn't all that still compile down to a bunch of machine code?
I assume that the big PLC guys do not publish any information on the machine code that run on their products, but then again maybe they do?
If I had a LLVM backend for a particular device and an appropriate hardware abstraction layer would it then be possible to just write my own code?
It would be so great if this was possible. Adversarial interoperability at it's finest.
None of this is trivial work: LLVM backends, hardware abstraction layers, etc., but it would be worth it. HALs could possibly be automatically generated given some kind of spec.
Do any of the off the shelf modular PLCs have a published instruction set?
Who's with me?
It'll either be compiled directly to machine code and linked with the "standard library" provided by the platform, or more likely compiled to a bytecode that is then interpreted.
That said, the problem isn't that the PLC compiles to machine code... It's that the platforms (deliberately) won't give you a way to provide your own machine code to run directly on the device.I can think of a couple reasons:
unsafe (in the Rust sense) and crashing with a segfault or overwriting arbitrary memory is not great when you're controlling machineryIt's one thing to know the instruction set. You'll then need to find a way to push your machine code across and link to the existing firmware so you can use existing functionality (communicating with peripherals, multitasking, etc.) or write your own version of those APIs.
Either way you'd need to know a lot about how the device's firmware and hardware is implemented, and I doubt it'll be easy to get access to that IP through legitimate means.
Instead of trying to hijack an existing device and flashing your own code onto it, a better approach (and less likely to involve lawyers) would be to build your own ARM-based device and create an open-source platform for using it as a PLC or motion controller. A motion controller is just an embedded device which targets CNC or industrial automation applications, after all.
There are a couple RTOS frameworks in Rust that you may be able to take advantage of.
"industrial contollers" they are only micro-controllers with the appropriate protections and their black box model makes it impossible for someone outside of their framework to program them
There are countless projects that make the transformation from a common board to an industrial controller
for example: https://www.industrialshields.com/industrial-automation-solutions-based-on-arduino-plc-raspberry-pi-202007-home
Major other reasons relate to liability and support. Once you modify a device you necessarily assume all responsibility for liability and support. There needs to be a hard legal boundary when this occurs, such as a signed document accepting that transfer of responsibility, because otherwise the vendor incurs the cost (in money and personnel time) of proving that you have modified the device and thus assumed that responsibility.
Many of today's IIOT devices are extremely power-constrained. Adding or modifying embedded code so that those constraints are exceeded will trigger a lof of support cost to the vendor. Likewise if modified code violates timing constraints. Building devices that interact with the real world in such environments requires a skill set that is learned with practice, largely from more-experienced colleagues. It's a long way from making a toy robot with an Arduino.
I'm sure PLC vendors have very good reasons for locking down their products. IDE licensing is obviously a good one and so is the legal one, but we shouldn't care about either of them.
rustc and LLVM are extensible. A static analyzer could be created to help programmers identify timing constraint problems or possible logic errors or anything else you can imagine. QEMU or something could be used to virtualize whatever PLC you're working with.
Imagine a plugin for VSCode that visualized all your I/O from just reading your code. And then tests it. That would be cool.
Of course we'll never get to do any of this.
If you could choose a PLC to be opened up so it could be developed on in whatever fashion you chose fit, what would it be?
Automation Direct has a ProductivityOpen product. With the ProductivityOpen platform you get all the great features of a standard Arduino plus the added power and reliability of an industrial controller.
LINK
I'm not sure of the status of Rust on Arduino, but it seems like you should be able to use Rust with these.
I have a question ... why does the code compile to wasm?
What is the reason to compile this to wasm and not use the standard asm?
https://github.com/Michael-F-Bryan/rustmatic/blob/master/wasm/examples/basic-runtime.rs
Thx for reply. But how does this relate to performance and real-time requirements?
Now it's gone I'm wondering what the reply was.
Ever since I heard of Rust and then WASM the thought of industrial controllers that ran WASM applications crossed my mind.
The idea being that the controller hardware could be pretty much anything, using any CPU architecture and whatever operating system. For security it would be totally locked down with no way to communicate with it apart from downloading WASM code to run. It would not run any such WASM that was not suitably signed if not encrypted. Basically as sand box.
As the creator of the Docker container system said "If WASM existed when we invented Docker we would not have needed to invent Docker.
For all this to work as any kind of controller the WAM runtime would have to provide services for using I/O ports, serial ports, ADCs, DACs etc. Usual controller stuff.
When it comes to performance we have more than enough of that it modern processors for many applications.
Similarly many embedded application's don't require real-time performance down to micro-seconds.
Such a WASM sand box system would fit very well for most of the remote embedded deployments I have been involved in for years now.
The reply merely pointed out that WASM code was designed, at least initially, for execution in browsers, and thus can run in many more environments than can architecture-specific, usually narrowly OS-focused, machine-level assembly. I deleted the reply when I realized that the context was a thread on industrial controllers, of which both you and I have had too much experience.
Th for reply.
But has anyone done WASM research from the perspective of real-time requirements (e.g. on the Linux Preempt RT platform)?
As for performance(no RT), I found a video like this:
WASM can be statically compiled upfront to any other CPU architecture, so it doesn't have any of the real-time difficulties that JIT or interpreters have. It also doesn't do any run-time allocation by itself. There may of course still be a execution time overhead from the cross-compilation, but nothing that affects timing predictability at run time.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.