Advanced Search

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

Yes machine work only with 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.

Are you saying that the only way it works is this

refClockSyncCycles="-1" syncToRefClock="false"

??????

the result is :

ethercat upload -p 0 -t uint32 0x1C32 0x06 return 0x00000000 0
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 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've already tested only refClockSyncCycles="-1" without syncToRefClock="true" and the problem persists.

I've also tested refClockSyncCycles="1" and syncToRefClock="true"
and the problem persists.

Do you want me to try deleting refClockSyncCycles="1" and leaving only syncToRefClock="true"?

Sometimes you do not have enough room for the tool outside of the machine limits.
Install home switches, set the tool centered above the part and set your G54 offsets and it will likely work fine. 

the radius error is related to your gcode. Sometimes from running absolute instead of incremental  arcs or vice versa,

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.
 

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.

I have looked in the code but don't see why it does what it does.
It is supposed to work like this
When the syncToRefClock option is given the "-" is ignored, "true" means to switch on, any other string means to not activate the pll code.
In lack of the syncToRefClock option, the "-" will switch on the pll code.
Your code doesn't react in that way.

Hakan is correct, but depends on device, we should check what they report.
could you run these?
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
Edit: also these please
ethercat upload -p 0 -t uint32 0x1C32 0x09
ethercat upload -p 1 -t uint32 0x1C32 0x09

Run these and write here the output, to confirm if sync0shift 0 is supported

Also

refClockSyncCycles="-1" syncToRefClock="false"
is self contradictory

use only 
refClockSyncCycles="-1"
or only 
syncToRefClock="true"

to enable PLL

Just be patient, I started from scratch today and got the framework working but some of the data is  incorrect.
In the mean time, learn how to build linuxcnc as a RUN IN PLACE version for testing
When I get a bit further, you will be able to clone my git repository and test it for me.

System Test Is Debian Trixie 13.3 , kernel 6.12.74 RT, linuxcnc 2.10 ( actual Master), Ethercat 1.6.9.

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

That's the right behavior even if the actual value is strange.

Which version of linuxcnc-ethercat (lcec) are you using right now during these tests?

Good morning everyone.
I did the following test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>

The problem returned, noise on the axes.

I ran this other test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="500000"/>

The problem returned, noise on the axes.

the lcec.0.pll-err pin in both cases reported a value of 0 for about 1 second and then changed to 5072592 for about another second, before repeating the cycle.

The only way to make the noise disappear is:
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>

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


I haven't tried :
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf and sync0Shift= values ​​other than zero.

The result of the command:
dpkg -l|grep ethercat on debian Trixie is:

ii ethercat-dkms 1.6.9.gb709e58-1+28.1 all IgH EtherCAT Master
ii ethercat-master 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat-dev 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master


same command on Debian 10, returns nothing.

if I run : ethercat version
IgH EtherCAT 1.5.2 unknown

 

I think you are using shiftTime in the wrong way.
Your work should focus on the SM2/SYNC0 distance, that it is sufficient.
shiftTime is a slave requirement, not a synchronization requirement.
My slaves work with shiftTime 0.
 

Learning how to actually operate the lathe I built, and I've confused myself over tool orientation.

Gang-tool lathe, with front and back tools.  Defined in INI as a back tool lathe, but that can change if needed.

I use Fusion for CAM, and the standard LCNC post for fusion.  The post handles front/back tool orientation by setting the 'turret' value in the F360 tool library to 103 or 104.  When the post sees a '103' for the turret, it outputs all X-moves with negative values.  Opposite for '104'.

While this results in appropriate tool motion, the LCNC backplot is wrong, kinda.  The toolpaths are appropriately displayed as negative X (below centerline), but the tool tip indicator is approaching across the centerline - looks kinda crashy.

Having researched the forum a while back about gang-tool lathes, I found the 'trick' about using G10 to rotate the WCS 180 degrees around Z for back tools.  So I've got a couple M-codes to do just that - flip back and forth between back and front tool views.

Caught me off guard the first time I flipped the X axis and jogs were backwards.  I somehow thought it was just the display/backplot that rotated...

But that got me thinking about the point of this long-winded post.  Can I use the lathe tool orientation value (parameter #5413) to drive the M-code WCS flip during a tool change?  And leave all tools as 'front turret' in F360 so the post only outputs X positive numbers?

I've got a lathe-fanucy test config on deck (remap T) for testing.  Maybe add a conditional check for the value of #5413?  Something like:

Anyone see any holes in my theory or suggestions for improvement?