I have an XHC-WHB04B pendant set up and everything works pretty well, except that when I turn the wheel in continuous mode it moves in jerks/jumps, while in step mode it moves smoothly. Is there any way to avoid the jumps in continuous mode?

isnt backwards.

Bit 0 (port 0) is 0x0001 and bit 15 (port 15) is 0x8000, because the "first" bit is on the right.
 

Thank you very much for all your hard work. I’ve been following this thread the whole time, and now that the changes are being incorporated into the official repository, I’ll update my repositories and test the new EtherCAT HAL driver.Note 1:From what I’ve read, there does appear to be a dependency between the software and hardware.Note 2:I would ask you to investigate whether Debian, the base thread and the servo thread can each be assigned to a single CPU core.This would further improve stability.This is also done by Beckhoff and Codesys.It makes their runtime independent of the operating system and guarantees real-time capability. 

A quick update from my end: I replaced the two components on the encoder board, but unfortunately, the encoder signal is still not being processed. Without a schematic, I really don't know where else to look.

I'm still waiting for the optocoupler so I can get the second board back up and running.

I recently stumbled upon this forum and the whole Linux based machining process.  I mentioned this to one of the upper management folks, I was told to do some research and see if it might be something that could be integrated.  So here I am.  Looking forward to this adventure.  
I first learned of Linux operating systems ten years ago or so, when I saw a Linux magazine with an Ubuntu operating system and how to install.  However I am not very skilled or adept at keeping up with ever changing technologies and so forth.  The core concept of Linux and open source principles really is something that caught my attention.  Anyways thanks for being here y'all and thanks for having me as a part of this organization.  Have a great day.

thanks for your help! I got the outputs working.

But now I have another problem.

I would like to add a door switch that triggers and Estop so nobody can access the machine while running. But the door switch will also be triggered when the machine is in idle and therefore I would have to home the machine every time the door has been opened.

Is there a way to unhome the axis only when the estop happened while an axis was moving?

Could this become the snowball that starts the avalanche?
Do I dare hope for a world NOT overrun by big corporate subscriptions ? 

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.

This is great news. There has been a lot of ethercat related development activity driven by grandixximo on both Linuxcnc and the linuxcnc-ethercat hal driver. When a few more things come together, I will be refreshing my ISO's which will put everything on the one ISO. 

Its great that Grandixximo is now the owner of the  linuxcnc-ethercat repository and he's implemented a number of changes with more in the pipleine. He's also got a PR with LinuxCNC that will provide a "hook" in linuxCNC to allow synchronizing the servo thread with Ethercat before the servo thread starts which should further improve results and perhaps remove that little squeak even..

Thank you for your endorsement of my kernel tuning optimizations. Its very valuable feedback being able to state Trixie (Ddebian 13) is as good as Debian 10 once tuned. Having a system that queries your PC as it is optimised has reduced manually tuned jitter by 50% in my testing. I have never been very rigorous about this testing as it needs to be installed on hardware  and I have to stuff around compiling a wifi driver every times so its easy to loose data but it seems to improve with every iteration as its given me a place to record every new optimisation I unearth.

At risk of upsetting some, you can find out more about my optimisations on my Youtube channel  www.youtube.com/@MrRodW or the companion website  mrrodw.au/  

Good morning everyone.
After a few weeks of testing on a station with drives and I/O peripherals, we managed to achieve good results with GRandixximo.
The work done by Grandixximo significantly improves EtherCAT performance, but it must be combined with the kernel optimizations that Rodw has developed.
Using these two optimizations, on the EtherCAT and kernel sides, we are approaching Debian 10 performance.
The Debian 13 solution, when stressed by simultaneously opening multiple browsers and graphical tools, sporadically made noise for a fraction of a second, both with refclocksync -1 and 1, but I'm sure that using a PC more suitable for EtherCAT, stable machines can be achieved.

On Debian 10, the drives do not emit any noise under any conditions.

Grandixximo will now prepare the configuration packages and documentation.
As soon as they are ready, I will be able to test them on a few other machines to confirm everything.

We thank all the participants in this discussion.