Ethercat random jitter fix

Are you saying that the only way it works is this

refClockSyncCycles="-1" syncToRefClock="false"

??????

Initially, everything seemed to be working fine, because I was testing a system with smaller motors, always from the same manufacturer, not connected to the mechanics. I noticed the problem when I started moving the axes on a real machine. Here's my experience:
-First of all, on Debian 10 with EtherCAT 1.5.2, I never used the :syncToRefClock parameter, only refClockSyncCycles.
-On a real machine with an ASD2 Delta drive, with the first I/O node being the same, if I set the refClockSyncCycles parameter to -1, the axes shook at the first movement.
If I set the refClockSyncCycles parameter to 1, the machine worked 99.9% of the time; only very rarely was I forced to reboot the system because the axes made noise the first time they were restarted.

Still on Debian 10 with ethercat 1.5.2, with the same I/O node, with a Veichy drive, the refClockSyncCycles=1 parameter causes the axes to shake. I had to set refClockSyncCycles=-1 to work without problems.

Debian Trixie ethercat 1.6.9, Veichy drive machine. I initially set the Debian 10 xml file, so with only refClockSyncCycles=-1, the machine makes noise.
I then modified the xml with refClockSyncCycles=-1 and syncToRefClock="false" and now the machine works correctly.

I haven't been able to test Debian Trixie with the ASD2 drive, but I think at this point it will behave the same as Debian 10, namely:
refClockSyncCycles=1 and syncToRefClock="false"

I therefore assume that the syncToRefClock="true" parameter is set by default if not added to the XML file.

Yes machine work only with refClockSyncCycles="-1" syncToRefClock="false"

syncToRefClock is false by default, your assumption is incorrect, are you sure you have built my repo's code?

then it should also work with 

refClockSyncCycles="1"

just the above don't add

syncToRefClock="false" or syncToRefClock="true"

your assumption is correct in the case you are testing.
refClockSyncCycles="-1"
will force syncToRefClock="true" because that is expected to respect old behavior

so your problem is PLL is causing the vibrations

Please run my commands again with only

refClockSyncCycles="1"

then run

ethercat upload -p 0 -t uint32 0x1C32 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x06
ethercat upload -p 1 -t uint32 0x1C32 0x06
ethercat upload -p 1 -t uint32 0x1C33 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x03
ethercat upload -p 1 -t uint32 0x1C33 0x03
ethercat upload -p 0 -t uint32 0x1C32 0x09
ethercat upload -p 1 -t uint32 0x1C32 0x09

I only tested refClockSyncCycles="1" without writing syncToRefClock, and the machine worked flawlessly.

The lcec.0.pll-err pin in this case reported a value oscillating from approximately 991902 to 994498.

The rest remained the same:
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>

The result is :

ethercat upload -p 0 -t uint32 0x1C32 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 0 -t uint32 0x1C33 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010000: Unsupported access to an object
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0

sorry, I got messed up, should test the ethercat upload commands with 
refClockSyncCycles="-1"

If you could also do some more testing, I'd really like to get to the bottom of this

also with refClockSyncCycles="-1" (don't move just start)

Check pll_reset_cnt, does it increment every ~1/sec?

Also could you move the first servo drive as the first slave, and try with refClockSyncCycles="-1"?




 

@rodw

rodw wrote:

Hakan wrote:

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.
 
Please expand on what you mean here.

This is a standard RIP install of Debian 2.10 except its in a folder under /usr/lib, grandixximos driver built from source, Ethercat from repos. That should make no difference. For me, latency etc is fine on my hardware which makes it weird.

 

In Scott's linuxcnc-ethercat repo pll-err oscillates around 0.
In grandixximo's repo pll-err oscillates around that number 992000 something.
It's not necessarily wrong, it was just how I could tell.

As mentioned, with only the refClockSyncCycles="-1" parameter, the axis makes noise, but it's only for reconfirmation.
Parameter values ​​are with refClockSyncCycles="-1"
ethercat upload -p 0 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0

I can't reverse I/O with the drive. I/O is always 0, the drives follow. I would have to change everything hal, but this configuration works fine with Debian 10 and now also with Trixie, but with refClockSyncCycles="1"

The pin pll , oscillation value about 1 second value 0 after 4210619, after 1 second restar with 0

please check hal pin
ecat.0.pll_reset_cnt

with refClockSyncCycles="-1"