Rust for PLC programming

Hi guys, I have been following use of Rust in embedded for some time now, and I’m impressed over the progress that is being made all the time.

I have been thinking lately over the possibility of using Rust in relation to PLC’s.

As you may know, programming of PLC’s is usually done in IEC61131-3, which is a collection of 5 languages, where Ladder logic and perhaps Structured Text (a textual language which is limited in ability by design (less footguns) and focused on maximum readability) are the most well-known. The focus I guess is foremost on ease of programming and troubleshooting/debugging.

It would be exciting do something in this space, like a ladder/structured text interpreter or something else to run on resource-constrained devices. PLC’s are similar, but another use case in relation to embedded systems. And I think there is some potential here for Rust.

What are your thoughts on Rust in this space, are there already some discussions or projects going on?

Thanks!

3 Likes

I’ve played around with this idea in the past. In particular, I started writing up a basic compiler frontend for structured text and got about midway through the program analysis stage before getting distracted.

The way I’d probably approach this is to write a compiler that runs on a normal PC and then a #[no_std] virtual machine which can run on your microcontroller. Compilation often requires lots of data structures and dynamically-sized collections, which isn’t great on a constrained device which may not even have an allocator.

2 Likes

Cool, is your description of the approach the goal of your project? Looked at your project, nice to see ecs used for new problems outside of games.

Hey guys. It’s really a cool initiation. I’ve been a PLC programmer for years in the automotive industry and I decided to abandon it since the tooling around development is quite poor.

Back at the time (can’t see much changes until now either) there was no real static code analysis tools, unit testing frameworks, integration to source control to mention the most painful ones.

I like the new features in IEC61131-3’s structured text but still I feel like it would be much better to introduce a modern language with all of its tools to the PLC world instead of falling back to restricted languages.

What do you think about a SoftPLC runtime that would execute rust code?

I agree that Rust is for sure a more safe and powerful language than Structured Text.

On the other hand, I guess sometimes readability and fast troubleshooting “on site” is rated higher than even the problems of the original programmer. Classic example is the technician who can easily read Ladder Logic, but not i.e. Rust. :smiley:

Maybe we could leverage some of Rust’s excellent tooling for even the 61131-3 code if the compiler etc. is written in Rust?

I’ve written something that goes that direction: https://github.com/birkenfeld/ethercat-rs

It’s basically a -sys binding to the IgH Etherlab master, so that a Rust program can communicate with EtherCAT slaves, and (the beginnings of) a higher level API.

The demo program shows how this looks currently. In addition to talking to Beckhoff terminals, most of the code implements an interface that we’re using @work to talk to PLCs from the software side, and exports this via Modbus. (This defines all the iface stuff and the state machines.)

At the moment, no attempt is made to get true real-time behavior, though this should be achievable with the right OS patches. It’s not a priority for us though.

Well I’ve been involved in PLC programming quite a lot, and we utilized a really cool framework with a lot of abstractions in a production environment. Two languages were used extensively, one was ST the other SFC, so no LD not FBD, because they are quite limited and after some complexity they tend to become ugly and quite unmaintainable.

So to wrap it up, our technicians could still easily fix any incidents, mostly due to the high level of diagnostics applied to the stations without even having to peak into the code base. But still when they had to debug the code they could understand it quite easily because of the APIs were easy to follow.

For a newcomer graphically represented languages may be easier to pick up at first glance but after some time they are quite limited and not suitable for complex machines we have nowadays.

1 Like

I really like your example. Maybe we could set up a slack channel and share ideas.

I honestly think that a SoftPLC runtime that could run rust applications to control various IO cards and components would be really beneficial for the future.

The PLC world could be easily introduced to other parts and people of software development, and I think would be much more fun :slight_smile:

Still thinking about this topic, how would the runtime look like. It would need to support some different things I guess, like monitoring of variables, download in run, compare with online. Some kind of interpreter of rust code? Just brainstorming here :slightly_smiling_face:

Indeed nice questions mate!

1. Monitoring of variables
I guess it should be done via a remote debugger. However I’m not sure what Rust can offer in that field, but I’m certain that it is feasible.

2. Download in run
I rarely used that functionality with SoftPLCs - even though it was available - mainly because the intensive usage of pointers in our software. Using hot reload could easily corrupt running code on the PLC because the memory got reallocated but the pointers had reference to memory blocks, and the content of those blocks had been overwritten during download.
So I’m a bit biased on this topic as I could live without this feature.
Although I can imagine scenarios when it’s a nice to have, for example stations that require high availability, but still I think it’s preferable to use redundant controllers for those systems.
I can also imagine using Kubernetes here, so while you create a pod for a new deployment the previous pod is still running, and once the new pod is created it takes control over from the other.

3. Compare offline/online
Well, according to what I’ve seen amongst SoftPLCs, you had the option to download the binaries together with the source code on to the controller.
Normally the source code download shouldn’t require too much resources because of its size, compared to the resource requirement of the running code.
However I feel like that using a modern language like Rust enables us to use more sophisticated processes to manage the deployment. One can set up a really nice deployment workflow using version control systems, automated unit tests, code linting with CI/CD platforms.

I am very interested in this topic. Although I am new to the Rust language (I came across it during research about languages that will be real-time compatible), I think that what @birkenfeld has put together is already an interesting start, and I am going to try and get it to run soon (once I can get some hardware).

I have been working in the industrial automation world for about 10 years now across several different industries, and the problems remain the same (code testing, speed of deployment, data access), but the solutions introduced by major vendors such as Siemens, Rockwell and even Beckhoff are lacking. I have talked with executives from all three companies, and they don’t take the conversations about open access or applying modern software principles to their platforms seriously (or at least their priority for such features is very low). It is quite frustrating.

There are a few half-started projects for open PLCs, see for instance OpenPLC, Beremiz, matiec, 4DIAC. I think part of the issue is there is not a big enough crowd of end users to keep an open-source project going, and with the lack of access to hardware, it makes it difficult to gain any traction. If you look at the embedded world as a similar example, each major vendor such as Atmel, Broadcom, STMicroelectronics all sell or provide free IDEs, which have the same problems a PLC IDE has - lack of good testing tools, crappy, unmaintained user interfaces, poor code automation support, etc. But the embedded world has seen the rise of tools and frameworks like PlatformIO, Arduino, mBed OS, etc which are slowly changing the equation and making it possible to target different hardware without relying on the vendors IDE and tools. I wish the same was true in industrial automation.

One thing I think would help with adoption is if the runtime is abstracted completely from the hardware, such that, by default, it is always possible to run the program with hardware disconnected. For instance, with EtherCAT, it should be possible to run the control software without the EtherLab driver installed, by using a mocked out I/O image that can be manipulated through software. It would be OK in this scenario to not meet any real-time constraints - e.g. the control software is designed to execute cyclically in bounded time during production, but perfectly acceptable to not meet these requirements in a testing / virtual environment.

This.
For sure it should be possible to run it in a simulated environment. Ideally the simulated environment should support “online” functionality like monitoring of variables etc.

Another thing is that there should be some “ergonomic primitives” so the PLC programmer dont have to go the whole way down to machine level “embedded style” if he has no need to, but can focus on the automation program (i.e. no masking in hex to read a digital input)

What do you guys think, should there be some repo with specification or discussion?, how do we proceed?, @birkenfeld, @Szabolcs has already have some good ideas.

This topic is tagged “Embedded”. There is much existing work in the Embedded working group that address issues such as the above, mostly in the form of already-working crates. I recommend leveraging that work rather than inventing something new.

Just found this one: Wow!

@dfreiberger You spoke from the bottom of my heart mate. Also I tried to reach out to the OpenPLC guy but he didn’t really get what I was talking about, and said that there’s already a platform that is open source and can compile the IEC61131-3 languages, which is not my point.

@krakers Some specifications would be really nice and should be the first step, like how to map Inputs, Outputs and Flags.
Also the run time should be versatile in terms of communication protocols. I think supporting Beckhoff hardware is a good starting point, because EtherCAT is really accessible nowadays, however a general approach would be desirable here, so the run time could act as a Profibus and an EtherCAT master (among others) as well.

Unfortunately I’m going to relocate in the upcoming month so I have a lot going on recently therefore I’m not sure if I can lead it, but would be really happy to contribute if you could think of anything specific.