EtherCAT - A pure Elixir fieldbus protocol

n0gg1n · March 7, 2026, 10:48pm

EtherCAT: A pure Elixir fieldbus protocol

Disclaimer: this is pre 1.0 and should therefore not be used in production yet

So what is EtherCAT?

It is just a fieldbus protocol (like Siemens Profinet, Modbus, etc.) with some interesting characteristics:

runs on Ethernet
allows all kinds of topology
is “open”
widely used in the industry

(If you want to learn more, this is a great introduction)

Since a quick demo tells more than a thousand words (and I forced myself to write this post without the help of AI ) here we go:

There are three Beckhoff IO modules:

EK1100 which is a Bus Coupler (the device with the two LAN ports)
EL1809 which is a 16-channel digital input terminal
EL2809 which is a 16-channel digital output terminal

As you can see in the video, each output is directly connected to the corresponding input. So when I set output 1 high, input 1 should also get high.

As you can see the master discovers all slaves, configures them and it just works.
Really fascinating if you ask me, since there is happening quite a bit behind the scenes

Why I wrote this library (and with “I”, I mean Claude + Codex)

There are mainly two reasons:

I would like to bring Nerves to the automation sector and make Nerves able to talk to reliable hardware.
I wanted to go with the hype and test some vibe coding

And I have to say the tools are insane. I would have never been able to write this library without the help of AI. I took so many different approaches:
I started with ethercat_ex, a Nif implementation of IgH EtherCAT, figured out that writing a Nif is not so easy in bare C, and switched to a Zigler implementation igh_ethercat. At one point I wanted to test an Erlang port driver ( GitHub - jannikbecher/igh_ethercat_port · GitHub ).

It is crazy how fast I can test different ideas. But I was actually already quite happy with my Zigler igh_ethercat implementation and thinking on how to publish it. But something still stopped me. I wasn’t really confident that the “glueing” of C, Zig, and Elixir would work reliably enough. There were so many moving pieces and two weeks ago I was sitting on the couch and thinking:
“All my problems I want to solve with this are actually quite slow compared to what the IgH EtherCAT implementation is solving. Why don’t I just try to implement this in pure Elixir? It would definitely make me more relaxed not to use a Nif.”

So I just asked Claude what it thinks and it pretty much one-shotted me a working library. I still can’t believe it and yet we are here…

But I’m still ambivalent. On the one hand, these tools are great and are helping dumb people like me to try different ideas. On the other hand, I’m shipping code which is not written by me. Much of the code is not even reviewed yet and there will definitely be bugs. And I don’t like this trend of releasing “barely working software”, but here is my reasoning why I did it nonetheless:

First of all, I created this library for an actual private use case and it seems to work really well. I don’t have problems with 10ms cycle times on a Rpi4 and I can even go down to 1ms. This is real-time servo control territory
I would like to reach out to the community, because I think there is great value to pursue this idea in a more professional manner. I’m currently at the end of my apprenticeship as an automation technician and I would like to explore in which way soft-real-time devices have their place in the automation world. Since I would like to continue my electrical engineering studies, which I stopped a few years ago, I think this could be a great topic for a bachelor’s thesis. So if you know someone, feel free to reach out to me

I hope there are people here similarly excited as I am! Thank you all for building these great tools I can depend on

n0gg1n · March 12, 2026, 6:08am

Introducing EtherCAT 0.3.0

new UI design: started as a joke, but I’m really starting to like it

feature rich hardware simulator: try it out and tell me what you think

mayl · March 12, 2026, 12:06pm

This is cool, I’m pretty interested in ethercat but haven’t had a chance to use it yet.

I’m not sure I understand how you’ve implemented a slave in pure Elixir, don’t you need a ethercat nic to turn the packets around without going through the network stack? I’m probably just misunderstand what you mean.

n0gg1n · March 12, 2026, 1:00pm

Hey @mayl, this is a great question and I definitely need to update the docs on that.
So the Simulator just opens a udp socket which the EtherCAT Master connects to and processes the frames like this:

github.com/sid2baker/ethercat

lib/ethercat/simulator/udp.ex

9750018da


      
          
          defp process_payload(state, sender_ip, sender_port, payload) do
            with {:ok, datagrams} <- Frame.decode(payload),
                 {:ok, response_datagrams} <- Simulator.process_datagrams(datagrams),
                 {:ok, response_payload} <- Frame.encode(response_datagrams),
                 {:ok, maybe_faulted_payload, pending_faults} <-
                   maybe_apply_reply_fault(
                     state.pending_faults,
                     state.last_response_payload,
                     response_datagrams,
                     response_payload
                   ),
                 :ok <- :gen_udp.send(state.socket, sender_ip, sender_port, maybe_faulted_payload) do
              {:ok, %{state | pending_faults: pending_faults, last_response_payload: response_payload}}
            else
              {:error, :no_response} -> {:ok, state}
              {:error, reason} -> {:error, reason, state}
            end
          end
          
          defp expand_fault_plan({:corrupt_next_response, mode}) do

The Simulator itself just reads the data-frames, manipulates them and sends them back, so it is deterministic.

(the way i implemented this was to use SOES as slave reference implementation and let Codex figure out the rest)

Does this make sense to you?

mayl · March 12, 2026, 4:28pm

Ok thanks, I think that makes sense to me. You can simulate the right bits coming back, but not at line speed the way a real ethercat nic can

n0gg1n · March 12, 2026, 7:05pm

That is not correct, or I don’t understand your conclusion correctly. The simulator is even faster, since it’s just updating structs. It can also simulate latency (which it already does). So you can generate all kinds of fault scenarios. Currently I’m improving the api and let Codex recursively try to come up with integration tests. Quite interesting to watch
Have you already worked with EtherCAT? Or are you interested in specific slave devices?

mayl · March 12, 2026, 8:41pm

What I mean is that a true ethercat slave starts transmitting to the next device in the train simultaneously as it receives. So without even needing the full frame to come in. That’s ns to us turnaround which is why it requires special hardware (ethercat NIC).

When I first quickly scanned the docs I (mis)interpreted that this implemented a ethercat slave in Elixir, which I don’t believe is possible to do in software

n0gg1n · March 12, 2026, 10:06pm

Ah now I understand. That is correct, but for this library the simulator is more than fast enough since it will for now only support cycle times >1ms.
Updated the docs in 0.3.1 release. Hope it is clearer now. Thank you for taking a look