EtherCAT Communication Issues, Lost Frames, Interruptions in Program Execution

Hi again.

While everything seems to mostly be in working order, I am not very happy with the behavior of the machine whenever there is some sort of error for whatever reason (user mistakenly jogs an axis out of bounds, disconnects cable, etc.). Whenever something like that happens, the PASIO (the IO controller of this setup) seems to trigger some hard coded defence mechanisms it has and I must restart the machine or the PC or plug and replug the cables until it goes back to the default state.

I am of the belief that this machine was originally intended to operate in a closed ring topology, especially since the final slave has an EC out and the onboard PC has 2 identical NICs. This on paper sounds like it would help when it comes to packets being lost. I am however having issues with configuring my EtherCAT driver to work with this.

From what I understand by reading the few topics there are on this on this forum and the docs of the EC Master , the option does exist to set a backup of an EC Master via The MASTER <X > _BACKUP variables. This, however, needs the driver to be recompiled with the --with-devices switch and setting it to a value > 1. I reconfigure my make files with...

...and then compile and install the driver with no errors. I edit my ethercat.conf to have the proper MAC for MASTER0_DEVICE, igb for DEVICE_MODULES and add my second NIC's MAC to MASTER0_BACKUP.

Yet this leads to the following error on every ethercat command:

Upon recompiling and reinstalling the driver without the --with-devices switch, normal behavior is restored. I honestly have no clue what is going on. I played around with some different config switches and reinstalling the driver multiple times, but this is the end result always.

I don't see ring topology discussed in the LinuxCNC or EtherCAT for Linux space at all and the documentation on the topic of redundancy is very scarce too. Do any of you have any suggestions? I'm considering opening up an issue on the EC-Master gitlab regarding this.

I am also contemplating making a separate topic on this on this forum since at this point the current hurdle is far removed from the initial topic. Would that be okay, or would it be considered spam?

PS. I solved the mouse issue, Tommy, thanks for your input. Your suggestion worked, but I also switched back to the onboard PC. It may be an older Celeron, but it has 4 cores compared to the 2 of the Core i3 I was using for a while, despite it being way more modern.

2 years later nearly and I managed to fix the issue after previously having nearly written the machine off as impossible to rescue.

I simply removed all PDOs that I do not use in my HAL from the EtherCAT XML. Seriously. That was it. `ethercat pdos` lists many entries and my colleague had populated the XML with all of them previously. Turns out, for this hardware, defining the ones you don't plan on using is a mistake.

Along the way I applied countless other fixes too, including changing the I/O control module to a Beckhoff EK unit, so I can't promise the fix wasn't a compound of everything I tried, but removing the PDOs was what made it click in the end. Everything else was way too numerous and way too long ago for me to recount and list here, sadly.

Another thing worth mentioning is that I found an old doc in the original hard drive of the machine that told me the PLL errors I had in dmesg were because of the 60C2 SDO. The slaves would not display its contents for some reason, but I was able to write raw data in it from the XML just fine.

Posting this so that it may potentially help someone in the future that is also dealing with undocumented Chinese hardware.