Is this ready for an R&D project about ethercrab HOT 6 CLOSED

I do ! I had an issue openning the socket with the release checkout but it seems fixed on the master branch ;)

from ethercrab.

Hey, thanks for taking the time to make a comparison! I think it's almost perfect, but I'll comment on a few things:

everything in one process
one process owns the ethercat master, no other can access them

The Client master struct is threadsafe, modulo #7 being released, so can be shared across as many threads as you like. The way the current API works is designed around groups of slaves, which can each be polled at different rates in their own threads (e.g. IO polled slower in a non-RT thread, servos polled quickly in an RT thread).

needs root priviledges (or linux capabilities) to open a raw socket

Yes, or the setcap command can be used to allow non-root access on the binary.

implemented in Rust

100%. I started this project because everything else just wraps a C library which is unergonomic in a Rust context and makes it very difficult to make any guarantees around thread safety.

fast heap-less implementation

Yep - everything is allocated up front.

cross-platform (even microships ?)

I develop on Windows and have tested EtherCrab on a Raspberry Pi a few times and both work. EtherCrab is designed to work on microcontrollers but a) no_std is not currently exercised so there are build errors and b) unfortunately requires an allocator to allow the group setup closure to work. The allocator shouldn't be required once a few more unstable features are stabilised.

might be faster than etherlab's implementation ?

I would absolutely love to see some benchmarks here! I'm not sure of the performance yet but I'll tentatively say "pretty good" as there's no dynamic allocation in the TX/RX loop. I've got some artificial benchmarks on my TODO list using criterion to give an idea of theoretical throughput fwiw.

Please also note that the current network driver is pretty terrible and could use a lot of work on the Linux side to e.g. use tokio for proper async TX/RX.

in early stage ?

Yes, however it does work pretty well with the slave devices I have! Even up to servo drives with a basic DS402 profile implementation.

Some other notes for your application:

• Distributed Clocks are not currently implemented beyond static drift compensation, so would need to be implemented for precise synchronised timing which I guess you need.
• The API will see some breaking changes over time as you/me/everyone gives feedback on what does/doesn't work.

Overall I'd say that yes, EtherCrab is ready for an R&D project. It's got a lot of rough edges but they can all be fixed, and there's no better way to fix them than to start using EtherCrab in a larger project than my test bench :)

from ethercrab.

Thanks for your fast answer
I will then try to make a small benchmark of PDO read/write of both crates and see what it gives :)

from ethercrab.

Sounds good! If you don't mind, please use git master as it has a couple of unreleased fixes in it :)

from ethercrab.

Hi Jimy, I'm doing some cleanup and closing a few issues/PRs. Hope you don't mind! Let me know if there's something you'd like to keep open, if you're still interested in using EtherCrab.

from ethercrab.

No problem at all, I should have closed them earlier myself ;)

from ethercrab.