Ethercat random jitter fix

It doesn't sound pll-related if you get clunks when idle/standing still.
You can try and record this. If the clunks are from commanded position disruptions
you should see it as disruptions in position feedback.
You can record long sequences to try to catch it. Use the "sampler" hal component.
Possibly add a ddt component to take the derivative of the position feedback.
It will show some spike/peak when a clunk happens, if there is something with the position.
Plot the data, and evaluate.
 

Like I said, clunks while moving an axis.
No Clunks or weird behaviour in still stand/idle.

I cant reproduce the issue sadly. Happens randomly.

On my setup it takes about 6 seconds to get OP, it's always been like that on my setup I have about 6 servos and 6 IO cards, you should link OP with emergency, you should not let anything be operational till all-OP is on. Without my patches, old Ethernet release there is no delay in OP?

You have to catch the spikes in the scope, scope the servo thread and you joint 0 Ferror or pos-cmd pos-fb

Without a scope reading it's hard to tell what's the issue.
 

Synchronization of slave clocks can sometimes take a long time at start.
There is a warning in syslog if it takes more than 5 seconds, or is it 30?
Don't know how to fix it, more than hope the slaves' clocks run more equal
when not being nudged by the master.
Add pll-err to the halscope plot. 

Hakan wrote:

Synchronization of slave clocks can sometimes take a long time at start.
There is a warning in syslog if it takes more than 5 seconds, or is it 30?
Don't know how to fix it, more than hope the slaves' clocks run more equal
when not being nudged by the master.
Add pll-err to the halscope plot. 
 

I saw at my own eyes synchronization of 120 seconds with beckhoff SoE AX5125 driver with older firmware ... its not odd behaviour 

beckhoff IPCs have sometime very similar behaviour with their own hardware from my close experiences...

endian wrote:

 
I saw at my own eyes synchronization of 120 seconds with beckhoff SoE AX5125 driver with older firmware ... its not odd behaviour 

beckhoff IPCs have sometime very similar behaviour with their own hardware from my close experiences...

The more i read here about ethercat = the less i like it.
Thank you for pointing out the quirks, not only the good stuff.
 

ethercat is the best from the best ... everything has some + / - ... finally synchronization issues and these childhood illnesses are not fault of the ethercat protocol itselft which is very robust... Its issue of HW at side of master, slave or connection itself ... 

If we use native bckhff driver at native stuff around these issues are suppressed limiting to zero ...

 

I’ve been following this thread with interest all along. What surprises me, though, is that I haven’t experienced the jitter issues described so far. I’d be interested to know what hardware you’re using. Perhaps there’s a correlations 

andrax wrote:

I’ve been following this thread with interest all along. What surprises me, though, is that I haven’t experienced the jitter issues described so far. I’d be interested to know what hardware you’re using. Perhaps there’s a correlations 

Its never been an issue for me  either. I did wonder the other day if newer hardware was  not a concern.

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.