Lucas (Jun 02 2026 at 10:45): Lucas (Jun 02 2026 at 10:45):Hi all,
As I mentioned in my introduction post, I work in a manufacturing facility as an Automation Engineer, and get to do a lot of cool work integrating different systems together into cohesive automation cells. Our automated cells usually center around a CNC machine with a robot for machine tending and sometimes include inspections with data feedback for correcting part dimensions on the next part that's made.
As much as I enjoy what I do, I can never shake the feeling that the tools we use in the industrial world are way behind what is available in the cutting edge software world. And the shortcomings can be broken down into 2 broad categories.
I need to write out a blog post or something to further flesh out the details of these 2 broad categories, but in the meantime I wanted to ask a question here anyway.
When I ran across Roc it got the gears turning in my head. Could one create a Roc platform that instead of garbage collection uses a concept of a fixed amount of pre-allocated memory? And could this maybe be a suitable candidate for replacing some, if not all of traditional PLC programming languages?
( I'm sure ladder logic will be around till the end of time, but it might be nice to have a "functional" alternative for some applications)
To be usable as the "brain" of an industrial automation system, this platform would likely need to:
I know this is a very broad, not very well articulated idea, but I wanted to start the discussion. Mainly to start getting it out of my head and see if it resonated at all with anyone else.
Thanks in advance for any input!
Lucas
Luke Boswell (Jun 02 2026 at 12:06):I have some experience with Roc platform development and I've also worked previously as a process control and automation engineer... but haven't touched the PLC side of things in many years.
I think Roc is very promising for the direction you are heading in, and it's why I invest so much time to help make it a reality. I have experienced these issues like vendor lock-in, poor tooling, and difficulty supporting or upgrading systems.
I'm not sure about all the details such as integrating with vendor tooling etc, but I think there is a lot of interesting opportunities to explore in this direction.
One of the platform concepts I have been thinking about working on is for Industrial IoT. Roc platforms provide a nice abstraction from the hardware which is beneficial in particular for resolving the non-functional requirements like security, reliability, maintainability, portability, testability (V&V), safety... which are common requirements in industrial projects.
Anyway, your ideas resonate with me and always happy to chat more :smiley:
Anton (Jun 02 2026 at 12:10):Hi @Lucas,
These are my quick thoughts without doing a deep dive:
Could one create a Roc platform that instead of garbage collection uses a concept of a fixed amount of pre-allocated memory?
I think so, in the past we planned to integrate with nea a webserver with predictable memory use. I'm not aware of any fundamental changes we made that would no longer make this possible. Note that Roc does not actually use garbage collection but automatic reference counting.
And could this maybe be a suitable candidate for replacing some, if not all of traditional PLC programming languages?
I have no experience with PLC programming languages.
be able to handle ModbusTCP, Ethernet/IP, Profinet, Ethercat, IOLink, and other such communication protocols
If those can be handled with C/Rust/Zig then Roc should be able to handle them as well. If any of those protocols are proprietary, that may complicate things.
somehow do "hot reloads" or "binary swaps" whenever possible
Hot reloads are planned some time in the future.
run completely deterministically as far as timing and memory.
timing is the one I am least certain about, we did not plan Roc for hard real-time systems. If you are only running a Roc program on your system, I would expect little variance between runs. But any update of the system, the Roc program or the Roc compiler could change the execution time.
Luke Boswell (Jun 02 2026 at 12:12):The key to your questions is in the platform development I think.
The application is compiled down to just plain data and functions, and the platform host calls these and is responsible for managing memory, passing in handlers Roc can use for allocating memory, and for managing effects like interacting with the "outside" world.
Luke Boswell (Jun 02 2026 at 12:20):@Lucas what CPU architecture do your PLC's run? Does your vendor tooling support calling C libraries?
I would think one place you could start is to take something like the zig platform template, modify that a little, build an app using roc build which can give you a static C library you should be able to load and call functions in your PLC somehow :fingers_crossed:
Lucas (Jun 02 2026 at 13:02):Luke Boswell said:
Lucas what CPU architecture do your PLC's run? Does your vendor tooling support calling C libraries?
I'm actually thinking of just targetting x86 linux, because when it comes to the scope of these projects, it would make total sense to just have an industrial PC on which the programmer can edit and deploy the code at the same time. Just for perspective, we routinely drop $2k on a PLC (very limited) and $4k on an "industrial HMI", whereas a nice industrial PC could do all the functions those 2 do plus more.
So while i'd love for this roc platform to be usable on constrained "embeded devices" I think it makes a lot more sense to target a full Linux PC that can run "Preempt_RT" (definitely don't fully undestand what that means... :joy: , but supposdely it translates to realt time capabilities on linux.)
@Anton , to answer your protocols question:
Thankfully these days, there's enough IO options out there that communicate over some form of TCP/IP (ModbusTCP, Ethernet/IP, and Profinet, + others) that the device doesn't necessarily need to support any direct hardwired IO.
Ethercat would probably be trickier since it doesn't use TCP/IP, but handles the RJ45 port data directly.
And Modbus, Ethercat, and IOLink are all open communication standards (with varying degrees of interoperability)
And @Anton , thanks for the clarification on automatic reference counting. I think I understand what that means... lol
@Luke Boswell
The application is compiled down to just plain data and functions, and the platform host calls these and is responsible for managing memory, passing in handlers Roc can use for allocating memory, and for managing effects like interacting with the "outside" world.
It's funny I had been brainstorming the overal project structure around rust/embassy for the past couple of weeks, but this is almost exactly the separation of concerns I came up with (definitely with some help by AI), once I get home later I can post the Architecture.md file I had kind of landed on.
I had been kind of leaning towards Rust, but would it be easier to start with Zig since that's what Roc is targeting at this point? ( I've made it about halfway through reading the Rust book and 0 experience with Zig, so really a noob to both)
Thanks again all!
Anton (Jun 02 2026 at 13:08):I had been kind of leaning towards Rust, but would it be easier to start with Zig since that's what Roc is targeting at this point? ( I've made it about halfway through reading the Rust book and 0 experience with Zig, so really a noob to both)
The new Roc compiler is written in Zig, but for the platform language Rust should work fine!
Anton (Jun 02 2026 at 13:11):This is currently the largest and most up to date Rust platform: https://github.com/roc-lang/basic-cli/pull/423
This is Rust platform starter template: https://github.com/lukewilliamboswell/roc-platform-template-rust
Arya Elfren (Jun 03 2026 at 08:50):Lucas said:
I had been kind of leaning towards Rust, but would it be easier to start with Zig since that's what Roc is targeting at this point?
Rust is a good default. However, one of the selling points of Zig is its c interop; if you foresee needing to interface with existing c libraries (proprietary, that don't have a rust wrapper, or haven't been re-written in rust) it might be easier.
Last updated: Jun 16 2026 at 16:19 UTC