Advanced Search

Because dcRefClock="true" only for drive 1 and not for all drive ?

I don't understand how can attachment file.
This test, are without your last fix.
I have executed N°3 test for refClockSyncCycles="1" and refClockSyncCycles="-1"


1° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

Master0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 105648
Tx bytes: 22401382
Rx frames: 105647
Rx bytes: 22401017
Tx errors: 0
Tx frame rate [1/s]: 1053 1050 752
Tx rate [KByte/s]: 360.7 359.5 216.8
Rx frame rate [1/s]: 1053 1050 752
Rx rate [KByte/s]: 360.7 359.5 216.8
Common:
Tx frames: 105648
Tx bytes: 22401382
Rx frames: 105647
Rx bytes: 22401017
Lost frames: 0
Tx frame rate [1/s]: 1053 1050 752
Tx rate [KByte/s]: 360.7 359.5 216.8
Rx frame rate [1/s]: 1053 1050 752
Rx rate [KByte/s]: 360.7 359.5 216.8
Loss rate [1/s]: 0 0 0
Frame loss [%]: 0.0 0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829434877492390059
Application time: 829434927369399203
2026-04-13 22:35:27.369399203


2° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

Master0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 201920
Tx bytes: 55838998
Rx frames: 201919
Rx bytes: 55838617
Tx errors: 0
Tx frame rate [1/s]: 1055 732 844
Tx rate [KByte/s]: 376.3 246.9 277.6
Rx frame rate [1/s]: 1055 732 844
Rx rate [KByte/s]: 376.3 246.9 277.6
Common:
Tx frames: 201920
Tx bytes: 55838998
Rx frames: 201919
Rx bytes: 55838617
Lost frames: 0
Tx frame rate [1/s]: 1055 732 844
Tx rate [KByte/s]: 376.3 246.9 277.6
Rx frame rate [1/s]: 1055 732 844
Rx rate [KByte/s]: 376.3 246.9 277.6
Loss rate [1/s]: 0 -0 0
Frame loss [%]: 0.0 -0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829435021988989029
Application time: 829435029703007959
2026-04-13 22:37:09.703007959

3° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">

Master0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 335803
Tx bytes: 102363460
Rx frames: 335802
Rx bytes: 102363095
Tx errors: 0
Tx frame rate [1/s]: 1062 800 845
Tx rate [KByte/s]: 375.7 272.1 283.3
Rx frame rate [1/s]: 1062 800 845
Rx rate [KByte/s]: 375.7 272.1 283.3
Common:
Tx frames: 335803
Tx bytes: 102363460
Rx frames: 335802
Rx bytes: 102363095
Lost frames: 0
Tx frame rate [1/s]: 1062 800 845
Tx rate [KByte/s]: 375.7 272.1 283.3
Rx frame rate [1/s]: 1062 800 845
Rx rate [KByte/s]: 375.7 272.1 283.3
Loss rate [1/s]: 0 -0 0
Frame loss [%]: 0.0 -0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829435160651165030
Application time: 829435171294192841
2026-04-13 22:39:31.294192841

1° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">


Master0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 394894
Tx bytes: 122081343
Rx frames: 394893
Rx bytes: 122080980
Tx errors: 0
Tx frame rate [1/s]: 1056 1001 811
Tx rate [KByte/s]: 345.4 327.0 265.2
Rx frame rate [1/s]: 1056 1001 811
Rx rate [KByte/s]: 345.4 327.0 265.2
Common:
Tx frames: 394894
Tx bytes: 122081343
Rx frames: 394893
Rx bytes: 122080980
Lost frames: 0
Tx frame rate [1/s]: 1056 1001 811
Tx rate [KByte/s]: 345.4 327.0 265.2
Rx frame rate [1/s]: 1056 1001 811
Rx rate [KByte/s]: 345.4 327.0 265.2
Loss rate [1/s]: 0 -0 0
Frame loss [%]: 0.0 -0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829435219977025031
Application time: 829435246614056284
2026-04-13 22:40:46.614056284

2° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">

Master0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 466209
Tx bytes: 145310656
Rx frames: 466208
Rx bytes: 145310307
Tx errors: 0
Tx frame rate [1/s]: 1055 865 766
Tx rate [KByte/s]: 345.2 278.2 243.7
Rx frame rate [1/s]: 1056 865 766
Rx rate [KByte/s]: 345.5 278.2 243.7
Common:
Tx frames: 466209
Tx bytes: 145310656
Rx frames: 466208
Rx bytes: 145310307
Lost frames: 0
Tx frame rate [1/s]: 1055 865 766
Tx rate [KByte/s]: 345.2 278.2 243.7
Rx frame rate [1/s]: 1056 865 766
Rx rate [KByte/s]: 345.5 278.2 243.7
Loss rate [1/s]: -1 -0 0
Frame loss [%]: -0.1 -0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829435319890377036
Application time: 829435334302407866
2026-04-13 22:42:14.302407866

3° power on with <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">

aster0
Phase: Operation
Active: yes
Slaves: 4
Ethernet devices:
Main: 68:ed:a4:79:15:bb (attached)
Link: UP
Tx frames: 555839
Tx bytes: 174885365
Rx frames: 555839
Rx bytes: 174885365
Tx errors: 0
Tx frame rate [1/s]: 1054 901 812
Tx rate [KByte/s]: 345.2 292.8 259.7
Rx frame rate [1/s]: 1054 901 812
Rx rate [KByte/s]: 345.2 292.8 259.7
Common:
Tx frames: 555839
Tx bytes: 174885365
Rx frames: 555839
Rx bytes: 174885365
Lost frames: 0
Tx frame rate [1/s]: 1054 901 812
Tx rate [KByte/s]: 345.2 292.8 259.7
Rx frame rate [1/s]: 1054 901 812
Rx rate [KByte/s]: 345.2 292.8 259.7
Loss rate [1/s]: 0 -0 0
Frame loss [%]: 0.0 -0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829435419653140029
Application time: 829435435462157958
2026-04-13 22:43:55.462157958

Die Widerholungen können mit repeat gelöst werden. Beim inkremental verfahren muss halt darauf geachtet werden, das auch nach einem Abbruch die empfohlene Grundeinstellung G90 wieder aktiv ist.

oder
 

I have commit a small change to enable you to set drive 1 as the reference clock please update the code from 

github.com/grandixximo/linuxcnc-ethercat

and run with this xml 


and confirm that DC reference clock is slave 1 and not 0 by running

ethercat master

in a terminal, I expect

Reference clock: Slave 1

Sorry, not a pin

it is the output to the terminal when you send this command
ethercat master
in a terminal window

it will list various things, I am interested in DC reference, and APP time, they are near the end

ethercat master command outputs
Master0
Phase: Operation
Active: yes
Slaves: 20
Ethernet devices:
Main: 00:e0:b4:68:34:0a (attached)
....
...
...
Distributed clocks:
Reference clock: Slave 0
DC reference time: 829391683702736097
Application time: 829391693979787340


the above is what I'd like to see, thank you
 

What parameters should I check?

the name the pin

salue zusammen,
ich habe ein wenig wegen dieser Thematik recheriert, nur komme ich nicht für Linux CNC auf Antworten wie ich sie verstehe und oder benötige.
Mir ist G Code zum fräsen noch nicht so geläufig. Bedeutet, ich möchte ein kleines G Code Programm schreiben welches mir mit der X Achse ein Verfahrweg von 100mm ins plus und wieder 100mm ins minus verfährt und zwar mit X anzahl Wiederholungen bis ich unterbreche oder bsi diese abgelaufen sind?
G 25 und G 26 scheint nicht verwendbar zu sein. Wie sehen G code Zeilen für Linux CNC aus die mir die Bewegung in der X Achse mit Wiederholungen, Schlaufe und oder Loop ausführt? 

lieben Dank schon mal im voraus
Claude

can you run ethercat master a few times consecutively while running with

refClockSyncCycles="-1"

and paste here the DC reference and the App time values?

at least 3~4 consecutive times please

do the same for 

refClockSyncCycles="1"

With refClockSyncCycles="-1" the value of the ecat.0.pll_reset_cnt pin is continuously increasing, it never stops, it increases in a positive direction more and more, in a short time it was already at 20,000

with  refClockSyncCycles="1" the pin ecat.0.pll_reset_cn remain stable = 0

please check hal pin
ecat.0.pll_reset_cnt

with refClockSyncCycles="-1"
 

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

@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.

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"?




 

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

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