3 ms·

I feel like a lot of people miss the point on PLC stuff. “Stale PLC programming languages” might be stale and in need of a rework, but “rewrite in rust” entire

I feel like a lot of people miss the point on PLC stuff. “Stale PLC programming languages” might be stale and in need of a rework, but “rewrite in rust” entirely missed the value proposition. Memory safety is important, sure, but these systems aren’t usually ever allocating memory or taking actions that aren’t deterministic. PLCs usually operate in strict realtime environments. Like each operation contains a known number of clock cycles, and is timed to match physical “stuff” moving in the real world. To rewrite in rust, you’d need a flavor of rust where you can deterministically know the timing of ops and calibrate the timing of each branch of any control paths. That said, there is a market for softer realtime PLCs and companies like Rockwell sell Windows IoT hardware- but they still contain a strict-realtime companion controller. Arduino is now selling a mountable PLC that can be programmed using their tools, but even they support traditional PLC programming languages.

cashsterling 3y ago
Yep... I programmed PLC's for periods of my career. I could write about this until my fingers fall off, but in short: Rust and C code can also operate in strict real-time embedded environments provided some basic rules are followed like "no dynamic memory allocation". This done all the time. If one follows hard real-time coding standards like Misra C or "JPL real-time C" (and these standards can also be applied to Rust, Zig, Ada, etc.) the code will run deterministically on a given target... just like PLC code running is not necessarily any more deterministic than C code (no dynamic allocation) running on an embedded processor. In fact, many PLC's today run a "PLC code execution" engine on top of a real-time operating system like QNX (which I think is mostly C code). Even in some older PLC's, it is still C firmware that's interpreting and running the PLC code. PLC programming "languages" (ladder logic, FBD, CFC) were designed for their programming audience, who are not software engineers. It is difficult to represent complex logic and numerical code in these languages and that limits the sophistication of algorithms that can be implemented on these systems. For instance: try writing a model predictive control routine in ladder logic; I think it could be done but I'd lose my remaining hair doing it. PLC Structured Text is very similar to Pascal and pretty capable, but folks generally don't write model predictive control algorithms in Structured Text either. It is hard to orchestrate multiple PLC to run as a cohesive, deterministic unit. The interfaces between PLC often need to be kept simple and sometime this communication is less real-time. Things are a lot more advanced in cluster computing. The limitations of current PLC architectures is already a pain point for complex control system, like large robotic manufacturing lines or optimal control of HVAC in large buildings)... and it's going to get worse as performance demands increase. Again, as mentioned above, I think Beckhoff and B&R are further along the evolutionary path than others in the industry.

cashsterling 3y ago

Yep... I programmed PLC's for periods of my career. I could write about this until my fingers fall off, but in short: Rust and C code can also operate in strict real-time embedded environments provided some basic rules are followed like "no dynamic memory allocation". This done all the time. If one follows hard real-time coding standards like Misra C or "JPL real-time C" (and these standards can also be applied to Rust, Zig, Ada, etc.) the code will run deterministically on a given target... just like PLC code running is not necessarily any more deterministic than C code (no dynamic allocation) running on an embedded processor. In fact, many PLC's today run a "PLC code execution" engine on top of a real-time operating system like QNX (which I think is mostly C code). Even in some older PLC's, it is still C firmware that's interpreting and running the PLC code. PLC programming "languages" (ladder logic, FBD, CFC) were designed for their programming audience, who are not software engineers. It is difficult to represent complex logic and numerical code in these languages and that limits the sophistication of algorithms that can be implemented on these systems. For instance: try writing a model predictive control routine in ladder logic; I think it could be done but I'd lose my remaining hair doing it. PLC Structured Text is very similar to Pascal and pretty capable, but folks generally don't write model predictive control algorithms in Structured Text either. It is hard to orchestrate multiple PLC to run as a cohesive, deterministic unit. The interfaces between PLC often need to be kept simple and sometime this communication is less real-time. Things are a lot more advanced in cluster computing. The limitations of current PLC architectures is already a pain point for complex control system, like large robotic manufacturing lines or optimal control of HVAC in large buildings)... and it's going to get worse as performance demands increase. Again, as mentioned above, I think Beckhoff and B&R are further along the evolutionary path than others in the industry.