Concession's for EtherCAT stepgens?

I Came across this video series a while back where the guy details some escapades making his own EtherCAT device. I posted about it in another thread. I believe the guy's name is Hakan on this forum.

Anyway he's been trying to get stepgen's working right and he just posted a new video explaining some timing issues he ran into


So by the end of it he explains that he got them to behave by running a 2ms servo thread, had to use an Intel NIC, and had to run kernel 4.19. That all seems like a dealbreaker to me. I'm curious if anyone has any thoughts on whether that actually needs to be the case. I know there's some Beckhoff pulsegen cards, anyone running those on a 1ms servo thread? I know the SPI interface between the ESC and MCU probably adds a bit of overhead over something like how Mesa does it but that seems pretty bad to me. Not knocking the work that was done but I'd pretty much rule EtherCAT stepgens out if that's how it has to be.

I know hakan has been dabbling with ethercat for a long time. My thought would be that you are far better off using an ethercat stepper drive with cia402 interface. Rtelligent have 2 channel (2 steppers) open and closed loop controllers ECR60x2 and ECT60x2. @scottlaird is playing with them so I'm waiting to see how far he gets building internal support into the ethercat hal driver. I'm sure he will sort it. I have a box of open loop Sanyo Denkai motors I'd like to get going. 
Leadshine also have something similar.
I have the ECT60 and a couple of the ECT86 (also in the mill) which is the NEMA34  single channel version of the ECT60. I could not get NEMA 23/24's going nice on the ECT86

Beckhoff use Intel NIC's exclusively for a reason. My mill is using Odroid H2+ with Realtek and it has not missed a beat (On Bullseye which does not have the r8125-dkms driver which I would try if I could!)

Yeah my video there.
Of course you should buy an EtherCAT stepper driver like Rtelligent ECT60 or ECT86 for any real work.
I have two of them and they work really fine. Fit right in the cia402 hal module.
There are several other low-cost alternatives for Ethercat stepper drivers if you go to aliexpress. And other places as well.

This is just a hobby project to see what it takes to make an EtherCAT device. I intend to use it, but not more.

The ect60 has a really nice and smooth step generation, despite what I see with occasional missing data. I wonder how they do that.
 

That's all kind of besides the point. I wasn't talking about buying an EtherCAT stepper drive or using Hakan's project directly....just discussing the issues found with timing and such as he's obviously did alot of testing.....

I'm not really concerned with why Beckhoff uses Intel NICs, there's about a million reasons that that could be the case and none of it necessarily has anything to do with whether any other NICs work fine or not. Likely has to do mostly with validation and some financial exclusivity agreement. Only problems I've encountered with RealTek NICs and Mesa cards were always resolved with drivers or bios updates.

Hakan didn't actually explain the reason for the 4.19 kernel or Intel NICs. I haven't used such an old kernel in a while but I would think the RealTek NICs would do alot better with newer kernels, 4.19 is at the end of it's rope anyway. I think the main issue described was a delay between the STM32 and the LAN9252. Not sure how much of that is firmware implementation but the LAN9253 is an improved version of the LAN9252. Not sure of the extent of the improvements but the migration docs state "improved cycle time" or something like that. LAN9253 is probably pin compatible in the TQFP package the way it's used here. If the SPI speed is the issue, both the STM32 and LAN925x support QSPI so that's another thought.

I'm curious what improvements could be had with something like a LAN9253 and maybe a newer STM32, like an STM32F7/H7. The thing I'm currently working on doesn't need any pulse gens or anything with real speed and I used a QFN package LAN9252 which the LAN9253 isn't available in so it's not something I'll be messing with soon. I may start working on something along those lines though

 

As for some benchmarks maybe you can check out this:
LAN9252 SOES
Check a few posts later where he also benchmarks the AX58100.

I know this is not really the same as the topic but I found it pretty interesting.
 

blazini36 wrote:

I'm not really concerned with why Beckhoff uses Intel NICs, there's about a million reasons that that could be the case and none of it necessarily has anything to do with whether any other NICs work fine or not. Likely has to do mostly with validation and some financial exclusivity agreement. Only problems I've encountered with RealTek NICs and Mesa cards were always resolved with drivers or bios updates.

 

Maybe I should have prefaced that this was conveyed to me by Beckhoff staff when at an Ethercat seminar in Australia where Martin Rosten from Germany,  the Head of the ETG spoke. At the time, I mentioned that we had network latency issues with some hardware on Linuxcnc. The reason Beckhof uses Realtek is technical, not commercial.  Fortunately, Ethercat is a more efficient protocol so less likely to be an issue.

The network latency issue was introduced to the Linux kernel with Bullseye and has never been fully resolved out of the box. IRQ pinning is the most effective method but BIOS, dkms drivers (only from Bookworm and up) and using a kernel compiled from pristine sources all help.
If Hakan is using the 4.19 kernel, it is to avoid the network latency issue and other so called "improvements" to the 5.9 and up kernel.....

rodw wrote:

blazini36 wrote:

I'm not really concerned with why Beckhoff uses Intel NICs, there's about a million reasons that that could be the case and none of it necessarily has anything to do with whether any other NICs work fine or not. Likely has to do mostly with validation and some financial exclusivity agreement. Only problems I've encountered with RealTek NICs and Mesa cards were always resolved with drivers or bios updates.

 
Maybe I should have prefaced that this was conveyed to me by Beckhoff staff when at an Ethercat seminar in Australia where Martin Rosten from Germany,  the Head of the ETG spoke. At the time, I mentioned that we had network latency issues with some hardware on Linuxcnc. The reason Beckhof uses Realtek is technical, not commercial.  Fortunately, Ethercat is a more efficient protocol so less likely to be an issue.

The network latency issue was introduced to the Linux kernel with Bullseye and has never been fully resolved out of the box. IRQ pinning is the most effective method but BIOS, dkms drivers (only from Bookworm and up) and using a kernel compiled from pristine sources all help.
If Hakan is using the 4.19 kernel, it is to avoid the network latency issue and other so called "improvements" to the 5.9 and up kernel.....
 

Probably going off the deep end a bit with the NIC thing. He's @ 2ms with an Intel NIC, so no idea what issue he's having with the Realtek but it likely has nothing to do with this....maybe just a troubleshooting step. I don't really recall the gist of your whole latency discussion but when I had issues with Realtek it was resolved by upgrading the BIOS on an H3 so that's a Hardkernel issue, not a Realtek issue. I haven't had any issues with Mesa cards @ 1ms on Realteks otherwise. I'm not running custom kernels, they're definitely newer than 4.19, but I'm not doing deep dives either cuz when stuff works I just leave it. So the 2ms thing is likely making up for something else.

RDA wrote:

As for some benchmarks maybe you can check out this:
LAN9252 SOES
Check a few posts later where he also benchmarks the AX58100.

I know this is not really the same as the topic but I found it pretty interesting.
 
 

I saw that, probably just glanced over it cuz it's alot of information and it's a bit hard to figure out what he's actually saying. His chart shows that using his own SPI driver (called SPL) that uses STM32 standard peripherals is much faster than the Arduino based SPI library. In his notes he doesn't really say that, he just talks about SOES itself. The last line in that chart doesn't look too much slower than the AX5100 stuff but it's much faster than the Arduino benchmark with the same STM32

I see it looks like Hakan is using Arduino, maybe that's an issue?

If anyone wants to check out the project in github, you can find it from here
ECAT servo