Open loop motors problem

I am having a very serious problem configuring my five-axis milling machine.
Until recently, it only had three axes, and everything worked fine.
For drives, I used 3 Nm Lichuan closed-loop integrated stepper motors.
Perhaps there were some underlying issues, but they were hard to notice because these servo-like systems are quite forgiving.
However, I added two more axes in a rotary/tilt configuration. The unit is actually too large for my milling machine—it fits, but only just, and it requires some clever workarounds to use. Modifying the unit itself is out of the question. It uses standard Nema 24 stepper motors paired with 1:50 harmonic drives. Judging by their appearance, the harmonic drives are more delicate than the theoretical torque output (motor torque multiplied by the gear ratio) would suggest; in other words, something is likely to break before the motors run out of torque.
So, that is not the problem.
The issue is that the motors are losing steps, and it is the fault of the controllers—specifically, Yitutoyo CL57 units (I bought a few while they were on sale).
These controllers can be set to either open-loop or closed-loop mode.
It seems there are either transmission issues or the controllers are freezing momentarily due to incorrect settings. This leads to a classic symptom: the motors stop moving and start humming. This happens at random intervals—sometimes occasionally, sometimes constantly.

Now, here are some technical details. The computer is a Ryzen 3 2200G, which exhibits very low and stable jitter—on the order of 20 microseconds. It uses an integrated Realtek network adapter (the system is a mini-PC, so installing a different one isn't possible). I also tested it on a more powerful Ryzen 5 system equipped with an Intel i210 network card; while it might be slightly better, the problem persists.
The operating system is Debian 13.7.
The software is LinuxCNC 2.10-pre1 (I’ve had nothing but trouble with the "pre-2" version—it’s practically unusable for me).
The drivers are as described earlier.
After many attempts, I managed to create a configuration file that allows the machine to run, but I’m not sure how reliable it is.
If the B-axis (tilt) were to stop at an arbitrary position, I could end up milling the machine itself instead of the workpiece—a scenario I’d very much like to avoid.
Below is an excerpt from the configuration file (irrelevant lines have been removed):
First, look at the initial line. I originally had `refClockSyncCycles="-1"`, which the Yitutoyo drivers absolutely do not like. I tried `0`, but that didn't work either; however, using positive values yields much better results. I settled on `10`, though I’m not certain if this is the optimal setting.
In the line for the TQ810 (Yitutoyo), I have `sync0Cycle="*10"`. Generally, higher values are better, but `10` is the maximum valid setting (anything from `11` upwards renders the driver unresponsive).
Meanwhile, for the TLC57-E (Lichuan), the setting is `sync0Cycle="*2"`. While it is possible to set a higher value, doing so triggers a "following error" during longer movements. Basically, it looks as if these two models are completely incompatible...
In desperation, I even considered switching to closed-loop motors, but that would have required raising the B axis by 30 mm—since the available models are that much longer—which would have rendered the machine useless.
I’ve ordered some Lichuan OL3-E57H drivers, though the Chinese sellers don’t seem to be in any rush to ship them (I always run into this issue with them). I figured that Lichuan components ought to work better together, but I suppose I’ll find out in due time.

And now, a question:
Has anyone encountered similar problems, or perhaps has an idea of how to resolve them?

Is having two masters a possibility on your setup? PCI network card? That's the only thing that comes to mind, when two devices don't like to be on the same line, then keep them apart.

2.10~pre2 is actively in development, not something you should use if you want stable, but if you want to help getting it there, please share the issue you found, possibly in a github issue

grandixximo wrote: 2.10~pre2 is actively in development, not something you should use if you want stable

You all keep repeating this like a mantra, as if it were meant to justify your mistakes.
And the cardinal error was breaking the rule: don’t fix what isn’t broken.
I saw discussions where you were warned about the inevitable consequences, yet you insisted on having your way and turned the code upside down.
Sure, in the past, things would occasionally stop working due to ongoing development, but someone would always fix them within a few days.
Now, the number of bugs is so overwhelming that I don’t see anyone ever getting this under control...

Let’s get back to the point.
The exact same configuration that works correctly on "pre1" (though I’m not entirely sure how stable it is) is practically non-functional on "pre2."
First, one of my axes is moving in the opposite direction.
Second, it’s flooding the logs with hundreds of the following messages—something that didn’t happen in "pre1":
Third, whenever I try to home just the rotary axis, it eventually ends with this error message:
Forgive me, but I only have one life, and I don’t intend to waste it tilting at windmills. I’m done trying—I won’t be reporting anything else.
You can play around with "pre2" by yourselves.

tuxcnc wrote:

grandixximo wrote: 2.10~pre2 is actively in development, not something you should use if you want stable

You all keep repeating this like a mantra, as if it were meant to justify your mistakes.
And the cardinal error was breaking the rule: don’t fix what isn’t broken.

This is quite unfair and verging on being rude. There is no need for the anger.
This change was not a decision made by Grandixximo. This change broke everything about ethercat. If you had any idea how hard he has worked to get ethercat up to speed following these changes, you might appreciate his support further. He's worked tirelessly and is also working hard on coding a cia402 homing module he forked from my repo which is currently under test on live hardware by a couple of users.

He's quite right. Use the development branch at your peril. Be willing to help him if you do decide to venture in but right now its not a good time... but it is going to be quite an enhancement to ethercat.

I think you are referencing the 2.9.9 changes where I had the parameters follow the docs, instead of changing the docs to match what the parameters were actually doing, I agree that was a bad move, and I should not have pushed for it, I learned from that experience, and will not let it happen again, apologies again, I'll do better in the future.

The bug fixing is not a single person effort, work in progress, I believe we will get there.

about the actual error, can you post the output of the following?

dpkg -l | grep -E 'linuxcnc-(uspace|ethercat)|ethercat-master|etherlabmaster|libethercat'

Edit:
Cross posted with Rod, I don't read the anger, criticism is fair, I'm not made of crystal