2ms cycle time for stepgens

[ShadeTechnik]

As I'm working on my own EtherCAT slave I was interested in the issue that caused the requirement for a 2ms servo thread to get the stepgens behaving correctly. I mentioned this to someone and they pointed me to a write up by Arthur Ketels where he describes some of the issues related to slaves misbehaving with distributed clocks. I'm not too familiar with this code implementation as it's not my strong suit but I'm curious if you think this could be part of your issue....

https://github.com/OpenEtherCATsociety/SOEM/issues/487

[MetalMusings]

Thanks for the link, good reading. It's like he writes, for some slaves this would pass unnoticed and it certainly would in most other cases. But for stepper motors it is soo easy to hear the slightest deviation in the tone. What he mentions are things I mostly not touch. Clock synchronization, state shifts etc is either done by the LAN9252 or by SOES and the only code I have written is setting a flag that says I run DC. The rest is handled by SOES. I am more leaning towards Linux and perhaps my installation. Here is a table I made with the linuxcnc hardware [image: bild.png] So I can get reliable 1 ms cycle times under some conditions. I ran this off the same USB SD-card installation. That can be source of the problem of course, it eliminates some other problems. The only thing I didn't check is the frequency of the LAN9252 crystal. I better do that. How are things going btw? Den fre 19 apr. 2024 kl 04:10 skrev ShadeTechnik ***@***.***>:

…

As I'm working on my own EtherCAT slave I was interested in the issue that caused the requirement for a 2ms servo thread to get the stepgens behaving correctly. I mentioned this to someone and they pointed me to a write up by Arthur Ketels where he describes some of the issues related to slaves misbehaving with distributed clocks. I'm not too familiar with this code implementation as it's not my strong suit but I'm curious if you think this could be part of your issue.... OpenEtherCATsociety/SOEM#487 <http://url> — Reply to this email directly, view it on GitHub <#8>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7HWRZEEAFXX2OM7CS2OLY6B4IJAVCNFSM6AAAAABGOK2DOSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TCOJTGA2DCMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ShadeTechnik]

Looks like you picture didn't show up.

It's hard to understand where the issue is actually coming from, or actually what the issue is. Are you able to run a Mesa card @ 1ms servo thread on the same system? You would think if there are no problems running a Mesa card that the PC itself would be capable of handling an EtherCAT slave @ 1ms as well hardware wise. Most of my systems are mobile CPUs on miniPCs with Realtek NICs and aside from bios issues I've always been able to manage 1ms with a Mesa card.

The PC stuff itself I'm not terribly concerned about, I'm trying to understand the issues on the slave side so I can avoid them if possible when I go to do a slave that actually requires good synchronization. Can you expand on the issue of the delay between IRQ and the STM32 reading data? I think it suggests that's only an issue on SM2, any issues on SM3? You also mention sometimes LinuxCNC is sending empty data which I suppose implies an issue master/ethernet. Do you think there are any issues with the STM32 itself? Do you think a faster STM32 or using QSPI between the LAN9252 and STM32 would be wise for a stepgen or encoder slave? I've seen some things that also suggest that Arduino could also be a bit of an issue with timing critical stuff.

I just finished assembling my slave card, I went with a LAN9252 and STM32F446. I'll be trying to do some basic tests today. My card is pretty much meant for dealing with control panel IO like analog inputs, low speed encoders, MPG etc., so there's nothing timing critical about it. Once I get that all sorted I would like to tackle a pulse gen, high speed encoder card. Hardware wise it's not really a problem, the software/firmware stuff seems to be the only real hurdle.