Advanced Search

I've added some debug pins in my repo

lcec.0.dc-time-valid
lcec.0.dc-time-mod
lcec.0.dc-time-delta

please use halscope to read the values you get, if you are on master you can save the scope log, and you can use the attach button, in the reply editor, to attach the file, or a picture of the scope.

would it be possible to get remote access to the machine via teamviewer host?
download.teamviewer.com/download/linux/t...iewer-host_amd64.deb
I'd really like to experiment with the hardware, really interested in checking why my PLL is not working for you, if it is a case of bad I/O or something else, possibly something wrong with some of my code assumptions.

can you email me if you don't want to post here the teamviewer access

luca at aitalmac.com

Is my personal email, thanks

You may have a timer issue, I know others had conflict with the timer and hbo4 pregnant, I would investigate that.

Aside from that I'm not sure what would cause that except maybe a setting for the pregnant specific that may require a change?

Hopefully someone else can come in with knowledge on it. My wired jog pendant uses velocity mode when the speed is to fast for motion and the pulses begin to stack up, this stupid a runaway axis condition.

You can set the overrides so you can go both ways while running, the settings are in the ini file, check the Sims for reference.

Both work. They are two different sync strategies, neither inherently better. It depends on which your drives like.

The two attributes are redundant and confusing. Negative `refClockSyncCycles` without `syncToRefClock` is the same as `syncToRefClock="true"`. The `syncToRefClock` attribute just explicitly overrides the sign convention. The code always takes `abs()` of cycles, so the sign is purely a mode flag.

With `syncToRefClock="true"` (or negative `refClockSyncCycles`), PLL runs every cycle regardless. The count value doesn't matter, only the sign. So `-1`, `-5`, `-100` all behave identically.

With `syncToRefClock="false"` (or positive `refClockSyncCycles`), the count does matter. It controls how often `ecrt_master_sync_reference_clock()` runs, every N cycles. `1` means every cycle, `1000` means once per second at 1kHz. Lower values mean faster convergence and more bus traffic. Watch `pll_err` and `dc_phased` pins to see when it locks. If it locks fast and stays stable, the value is fine. Examples in the repo use 1, 5, or 1000.

My take: positive cycles with `syncToRefClock="false"` is slightly cleaner, because the PLL stops once locked and less continuous computation happens, provided your drives tolerate the master as clock source. Yours do.

Recommendation: Use `refClockSyncCycles=1 or -1
Synctorefclock is just confusing.

jetbadger wrote:

 In that setup it should be the same as X/Z axis but it's still acting drunk. 

How is the servo connected to the spindle?  My biggest problem a couple years ago when I started fiddling was that my spindle servo was WAY undersized for use as a direct-drive positioning motor.

I had a "2.2kw" BLDC servo connected through a 1.5:1 belt drive.  Soon as I put a chuck on the 5C spindle the inertia ratio was so unfavorable the servo couldn't really handle precise positioning.

I now have a comparatively monsterous 3.7kw (actual rating, not inflated) motor connected to the same spindle through a 2.5:1 belt.  Night and day difference.  That motor can horse the spindle around like it's barely there.

Maybe you have a significant inertia mismatch?  Don't want to throw you a red herring, but something to think about.

That makes sense, I didn't really think of what the INI parameter is actually connected to, but that makes sense now.

I'm still not wrapping my head fully around the velocity/position mode thing. It does make sense that if you have the drive in same scale and always in velocity mode both in stepgen and the drive that the scale shouldn't be crucial and the PID could take care of it, but having it the way I do which is stepgen in velocity and drive in step/dir position mode to me seems like should have to be the same thing, but it isn't for some reason.

I've spent some time today on the schaublin and the C axis hurdle. Some new progress is that I think it all has to do with the PID ratios and acceleration. I played around with it watching the plots and in the end it got slightly better, but the commanded position is still progressing very slow.

I've looped back the stepgen position-fb instead of the encoder for everything and it's still the same as with encoder so I'm still baffled. In that setup it should be the same as X/Z axis but it's still acting drunk. Maybe I'll think of something else as I didn't spend too much time today on that, instead did some other functionality of the machine, which is more practice in hal and ladder so maybe one day it'll all just click

Hier einige links zur Dokumentation


Info über Parameter
linuxcnc.org/docs/stable/html/gcode/over...ode:named-parameters

o Codes
linuxcnc.org/docs/stable/html/gcode/o-code.html#ocode:repeat

G-Codes
linuxcnc.org/docs/stable/html/gcode/g-code.html

That looks good.
The error is normal; it happens when LinuxCNC shuts down.
Can you move the axis in jog mode without any problems?
If so:
You now have two options. Connect the remaining axes and use the CIA402 homing.
Note: Prone to errors with gantry setups
or
Use the LinuxCNC homing. However, this is significantly less accurate.

If there are battery-powered encoder cables available for your servos,
install them, and you’ll save yourself the homing process and avoid any further trouble.

 

A question.
So is it better to work with refClockSyncCycles="1" or with
refClockSyncCycles="-1" and syncToRefClock="false"?
If the two settings are equivalent, does the value of refClockSyncCycles have to be 1 or can it take on values ​​other than 1, and how do I know what the correct value is in this case?

vielen Dank, Deine Zeilen muss ich noch lernen zu verstehen und oder ergänzen,

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

DC reference time: 829435419653140029
Application time: 829439464192168202

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

DC reference time: 829435419653140029
Application time: 829439529368163181

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

DC reference time: 829435419653140029
Application time: 829439568792164528

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

DC reference time: 829435419653140029
Application time: 829439599360167607


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

DC reference time: 829439756498240034
Application time: 829439771336260988

2° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439799640262918

3° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439828648257947

4° without power on <master idx="0" appTimePeriod="1000000" refClockSyncCycles="-1">
DC reference time: 829439756498240034
Application time: 829439854792266116

Yes, the reference is only one, and right now is 0, and that I/O might not be doing DC properly.
So I'm try to move it to the servo.

The ethercat master, I'm only interested in two values 

DC reference time: 
Application time:

And three times on the same run, not one time per run. Sorry about not being clear about it. Appreciate it if you could test it, thank you.

Manda il comando tre volte dopo aver iniziato, non una volta per avvio.

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