I wrote rust-ethernet-ip because the gap between industrial automation and modern software engineering is still too wide. On one side, there are PLCs, HMIs, machine builders, production lines, and equipment that must run reliably. On the other side, there are developers who expect package managers, tests, memory safety, clear APIs, and language bindings that do not feel like an afterthought.
EtherNet/IP is not an academic protocol for me. It is the way many real machines talk to Allen-Bradley CompactLogix and ControlLogix PLCs. If a library only works in a simulator, or only demonstrates a happy path, it is not enough. The important question is whether it can connect to real hardware, survive real engineering constraints, and become boring enough to use as infrastructure.
The problem was not just connectivity
There are many ways to move data in and out of a PLC. The harder problem is building a driver that fits how engineers actually build systems today. Industrial teams increasingly need to connect PLC data to services, databases, analytics tools, dashboards, test benches, machine learning workflows, and higher-level applications. A driver should make that integration easier, not lock the team into one runtime or one vendor-shaped workflow.
I wanted a foundation that could serve more than one audience. Rust gives the core library a strong systems-programming base. C# matters because .NET is common in industrial applications. Python matters because scripting, data analysis, and machine learning workflows are increasingly part of automation work. The point was not to write a Rust demo. The point was to build a library that could sit underneath practical industrial software.
Why Rust
Rust is a good fit for protocol work because the details matter. Packet structure matters. Lifetimes and ownership matter. Error handling matters. Long-running software that talks to machines should be explicit about what can fail and how those failures are represented.
The value of Rust here is not hype. It is the ability to write low-level networking code without giving up modern tooling, memory safety, and a package ecosystem. For industrial software, that combination is important. A PLC communication library is not a place where hidden undefined behavior or casual memory handling should be acceptable.
The goal was simple: make Allen-Bradley PLC communication available through a modern, testable, open-source library that can be used from Rust, C#, and Python.
Real hardware changes the standard
The library has been validated on real Allen-Bradley hardware, including a 5069-L320ERMS3 on firmware 35 and a 1756-L81ES on firmware 37. That detail matters because industrial protocol software is full of edge cases that do not show up until you leave the comfortable world of examples and start talking to actual controllers.
Real hardware forces a different level of seriousness. You discover where assumptions are too loose. You learn which errors need to be surfaced clearly. You find out whether your API is usable when someone is trying to commission a machine, debug a line, or integrate PLC data into a larger system.
Shipping matters
I also wanted the project to be distributed like real software. The Rust crate is published on crates.io and has more than 5,000 downloads. The .NET package is available through NuGet. The wrappers are not decorative; they are part of the strategy. Industrial software teams do not all live in the same language, and a useful library should meet them where they are.
Open source is part of that same strategy. Industrial automation has too many important systems hidden behind opaque tools, closed integrations, and outdated scripting environments. A driver like this gives engineers something they can inspect, test, extend, and build on.
What I learned
The biggest lesson is that industrial software needs both domain knowledge and software discipline. Knowing PLCs is not enough. Knowing Rust is not enough. The useful work happens in the overlap: understanding how machines are commissioned, how production environments fail, how protocol details behave, and how to turn that into APIs that other engineers can trust.
That is also why this project connects to my broader work. I am interested in industrial systems that are open, programmable, and ready for modern computation. EtherNet/IP connectivity is one layer of that. HMI platforms, Python scripting, machine learning, databases, and traceability are other layers. The common theme is the same: bring modern software engineering closer to real machines.
What comes next
The next step is not only adding features. It is continuing to harden the library against real usage, improving documentation, expanding examples, and making the bindings easier to use from different environments. A communication driver becomes valuable when it disappears into the background and lets engineers focus on the system they are actually building.
That is the standard I want for rust-ethernet-ip: not a student exercise, not a thin wrapper, and not a protocol experiment, but a production-focused foundation for Allen-Bradley connectivity in modern industrial software.