@andrax
No need to apologize, just trying to understand where you were going with it.
With my fork I don't have any jitter noise when things are set as they should. Finding the issue was no easy feat, before looking at linuxcnc ethercat, hardware wise I tested with  different servos, different CPUs, different network chips, software wise, different ethercat versions, different kernels, different linuxcnc versions. Ruled out basically everything else, I knew it had to be linuxcnc-ethercat, and after putting in the time to find the issue, I am sure I found it, while before it was random, I can now reproduce it at will, and I can turn off the jitter at will, I can place the phasing in and out of the jitter with the sync0shift setting, this is correct and expected within the ethercat standard, even twincat has a default Sync0shift of 30% cycle time, and you should expect issue somewhere between 0 and 30% what issues will depend on hardware, but the standard does not want your Sync0shift in that range for a good reason, and the hardware is not supposed to work properly when you don't follow the standard, and the original code was NOT following the standard, maybe accidentally on some hardware it was ok, even a broken clock is right twice per day...

@Endian
I only use pos-cmd mode, i think velocity and torque mode can get better performance, give you more control, but require more tweaking, and I think (but not sure) any slight issue like the jitter of this topic might be absorbed by a finely tuned PID for the job.
While pos-cmd rely on PID of the servo, it's normally a general one, which will work for most applications, in my case it's very strict and quick, that's why the motor vibrates, it's trying to respect position very strictly, which usually is a good thing...
 

Looking more carefully at the HAL  file I suspect that it has to do with the offset component
or offset thread order.

EDIT:

Don't the mux components need to be addf'ed  before the offset component?
(since their outputs are used by the offset component)

This is also suggested by the fact that this only happens on the joint with offset applied.

I am aware of the ! prefix in GEOMETRY — it is already set in my config (GEOMETRY = !-BXYZ).

However, as the documentation states, this provision applies for liveplots only. I am using qtdragon_hd, not AXIS. Does the ! prefix in GEOMETRY have any effect on the qtdragon_hd backplotter, or is it AXIS-specific only?

Have you already compiled the gearbox comp? I have attached my HAL and Ini files, so you can see the pins you need to connect.

Cheers;
Mark

grandixximo wrote:

The linuxcnc-ethercat current release does not respect the ethercat standard, it has time phasing issues, this is demonstrably true.
Anyone lucky enough to not experience any issue has:

Not used pos-cmd mode.

 

what do you think with not to use pos cmd mode ? do you have an unreliable experiences with them?

Sorry,

It was just a thought. And no, I haven't had any jitter problems so far, despite endless restarts. I've often even had to restart the servos mid-operation (homing failure).
I'm absolutely certain that your driver is working and resolving the jitter issues.
But what if the hardware isn't compatible or is causing problems...?
I just wanted to throw that out there.

Sorry.

What are the clues supposed to point us to?
I have igc i210 advertised as supported by igh and Beckhoff.
There maybe a lot of reasons why your setup works for you, but there is only one cause for the jitter noise I was experiencing, there maybe other unrelated noises on other hardware, but the one I identified is fixed in my fork of the code.
What will figuring out why you don't have the issue get us? Did you run extensive testing with restarts looking at the halscope to prove you don't have the issue?

Interesting.
My computer is an ancient IPC from 2006. Except for the SSD, everything is original hardware.
The network card, however, has an Intel chip and is Beckhoff certified.

infosys.beckhoff.com/index.php?content=..../9309844363.html&id=

Perhaps that's a clue.

The linuxcnc-ethercat current release does not respect the ethercat standard, it has time phasing issues, this is demonstrably true.
Anyone lucky enough to not experience any issue has:
Incredibly low latency
Servos that somehow adjust phasing themselves further than what the Ethercat standard dictates.
CPU with instruction execution timing consistency across processes, somehow doing the phasing properly even if the code did not directly intended it.
Some servo feature that filters the commanded position.
Not used pos-cmd mode.
Not actively been looking for it, restarting 100+ times and induced high latency, and looking at Ferror and servo-thread in the halscope.

---

Even if some hardware is not bothered by wrong phasing, you should not blame this on the servo drives manufacturers. The software they are interfacing with demonstrably does NOT respect the communication standard.

It's the current release 2.9.7

(Edit)
Had to go look at what was actually on the machine, and it's 2.9.8 running on Debian Trixi.

I've used LeadShine and XingJie same issues with both, there may well be mitigations on the servos side for some manufacturer, but that does not mean the standard of Ethercat says they should be doing such a thing. So it's luck?

 
Hi,

I have a 4-axis MPCNC with a rotary B axis mounted at the far end of the Y travel (machine Y=700mm). The rotary axis is fixed — it does not move along Y.

G-code is generated by CAM with program zero at the chuck face, all moves go in Y-.

The problem: the backplotter does not display the toolpath correctly. Instead of showing the wrapped toolpath around the tube near the chuck, it draws a large circle. I believe this happens because the backplotter uses machine zero as the centre of rotation rather than the actual chuck position.

Setup:
- LinuxCNC 2.9.8 stable
- trivkins coordinates=XXYYZB, 6 joints
- qtdragon_hd interface
- GEOMETRY = !-BXYZ

Is there any way to tell the backplotter where the centre of rotation is?

Theoretically the problem is there. 
Some drives may be better than others to conceal the problem.
When you use syncToRefClock and don't hear it you will not hear it.
I mean the drives will not suddenly start being noisy.
The chance of hearing it is roughly every servo loop time/jitter start of linuxcnc.
With 7 microseconds jitter, you can hear it every 142'nd start of linuxcnc.
And you hear it throughout the linuxcnc session.

I thought my drives were immune to this, but after carefully listening I found they also
experience this, but they don't sound awful, just a very mild "tic".
The drives don't have to make noises, but they should definitely react to it.
It's basically a disturbance in the position flow, requesting an artificially very high or low acceleration.

clayton2ndtry wrote:

This rang a bell from when I wrote a terminate-and-stay-resident PC-DOS (stop laughing) program that intercepted data.

I did something similar but it trickled point of sale transactions out of a cash register to accounting software (And I got paid for it!)