Realtime Performance

[noumanqaiser]

Hello, Thanks for creating this amazing library.
I have a few beginner questions as I am very new to Ethercat.

Is this library suited for production use or is still in early phases? My interest is primary in Remote IO modules, are all IO modules with Ethercat compatible, is there List if tested/stable hardware?

My last question is, Twincat and some other software utilize a dedicated core to achieve an ear realtime behaviour on a windows based operating system. Does this library try to achieve a real time operating system behaviour aswell, is yes how?

[Apollo3zehn]

Is this library suited for production use or is still in early phases? My interest is primary in Remote IO modules, are all IO modules with Ethercat compatible, is there List if tested/stable hardware?

You may use it in production, but on your own risk. It is based on SOEM which is quite stable. However, the problematic thing is often the configuration of your slaves. More complex slaves often need to be configured properly using slave-specific SDO commands/data which you can also find in TwinCAT's "Startup" tab.

I am not sure what you mean by I/O modules? All EtherCAT modules are compatible with the EtherCAT protocol and so all modules are compatible with EtherCAT.NET. But as I said above more complex slaves need special startup code that you either find out via TwinCAT or the slave's documentation. TwinCAT itself often provides special UI pages for more complex slaves which EtherCAT.NET does not.

My last question is, Twincat and some other software utilize a dedicated core to achieve an ear realtime behaviour on a windows based operating system. Does this library try to achieve a real time operating system behaviour aswell, is yes how?

No EtherCAT.NET is not realtime capable. With the right network card (Intel) and disabled interrupt moderation (https://github.com/Apollo3zehn/EtherCAT.NET/issues/7) I was able to sustain a cycle time of 100 Hz. You can also use the RtTimer mentioned in the README do improve the cycle time stability.

That is one of the reasons I try to reimplement the EtherCAT protocol on my own purely in C# and then the critical code path will not contain any allocations so that no garbage collector can ruin the real-time capability. Or I do it in Rust as a learning project. But that depends on Rust's environment to e.g. easily read XML files and so on. Also I would like to build a simple browser-based UI and that makes most fun with Blazor + C#. So I have not decided yet.

[Apollo3zehn]

I forgot to mention that the GC-free reimplemtation of EtherCAT.NET should then run on a Linux kernel with PREEMPT_RT patch applied so that it runs on a real-time capable OS.

[noumanqaiser]

Exciting Stuff. 100 Hz/10ms scan time is a decent performance, comparable to average PLCs.

So with the plans you have, would you want to run EtherCAT.NET on a realtime-Linux Kernel and have Client application (e.g Blazor) running on non-Realtime OS(e.g Windows) talking to the Realtime Linux over virtual TCP, is that the plan? Do you think this could bring down the scan time to nearly ~1ms

[Apollo3zehn]

I plan to have two different processes, one with the EtherCAT IO Update loop (highest process and thread priority) and one for the rest including the web server (low process and thread priority). Communications between both processes via TCP vor shared memory or both.

With that setup the cycle time can be as low as 100 us, maybe even lower, my last test is a few years old. Now I have much more Linux experience and the systems got better performance.

However, I need to first finish my other project PureHDF where I am working hard on a release so that I get more time for other projects.

[noumanqaiser]

That's amazing stuff and best of Luck, if you manage to get this to work in a stable manner on famous Linux boards (e.g Raspberry Pi), there would be a lot of applications for it. I have some experience with C#/.NET/Blazor. Would be happy to contribute.

Nouman
noumanqaiser at gmail.com

[Apollo3zehn]

I have also thought about running it on a raspberry, I think v4 would suit for this application. I heard that the previous versions share the same bus for network/memory and that could make the cycle time unsteady. But I have not measured it.

The git project for the new implementation is already there: ManagedEtherCAT. But it is empty for a new years now. Hopefully I will be able to start with it this year. I guess (but do not promise) around fall '23 I will find the time for first tests.

Once the basic functionality and project layout is there, help for advanced features is much appreciated.