Advanced Search

What I wrote was
linuxcnc ask the slaves to sync to it every 5 cycles

"It" being linucxcnc servo thread.

But you understand
"Linuxcnc servo loop synch to the EtherCAT master."

That's not what I meant

It was a simplified model of how it actually works, just to have a rough model in the users mind.
positive refClockSyncCycles has linuxcnc-ethercat ask ethercat-master to ask the slaves to do the sync by sending the clock time.
this is how it always worked I think...

what I did for positive refClockSyncCycles, I added an initial bang-bang to nudge the servo loop in the correct phasing with sync0shift, not ideal but it works, after that is done every x specified cycle we set the time again, this works well.

there are two main causes of the grinding noise, one is clock drift, this happens if you have
refClockSyncCycles=0
nothing stops the drives and linuxcnc to drift apart
the second is servo thread startup time having a random offset with sync0shift , to fix this you can either use PLL with refClockSyncCycles=-1, which is constant PLL every cycle, or set refClockSyncCycles=5 for example, and in this version of the code I shared, it will bang-bang for the first 100 cycles only, to find proper shift, and then just set time every 5 cycles.
 

grandixximo wrote:

TAKUYA wrote:

Now as in just recently or in the patch from last year? or reaaally recently
Also, what does the refClockSyncCycles value do and is there any baseline on what to set it at?
 
github.com/linuxcnc-ethercat/linuxcnc-et...84ef36b53f0b734eaedf
the above is my patch, which I tested on real hardware, both 
refClockSyncCycles="5"
or any other positive number, this will have linuxcnc ask the slaves to sync to it every 5 cycles, put in whatever number you need to get phased in the time frame you desire, 
 
 

Did you change this because that is not how it works today.
refClockSyncCycles sets the time of the EtherCAT master (and from there, the slaves).
Linuxcnc servo loop time and speed is different from the EtherCAT master time and speed,
that's what causes these synchronization problems.
No value of refClockSyncCycles will make the linuxcnc servo loop synch to the EtherCAT master.
Except a negative which activates PLL which is a different thing.

Atsu wrote:

I could share my experience with this issue. Attached is a link to a video showing how the jitter sounds on StepperOnline A6 servos. This is exaggerated by disabling the synchronization. Once synchronization is enabled (syncToRefClock="true" or refClockSyncCycles="-1"), it still happens but much more rarely, just like grandixximo explained at the start of this post. Last week, I upgraded to the latest version of linuxcnc-ethercat, and am currently testing how the changes committed at the end of 2025 affect my machine configuration.

​​​https://imgur.com/a/FXSuvOS
 

Thank you for the independent testing, if you want a better version

github.com/linuxcnc-ethercat/linuxcnc-et...84ef36b53f0b734eaedf

this I have tested and works well, unfortunately Scott has not been around to merge it, so it is not in the main linuxcnc-ethercat repo yet, but it is a better version

TAKUYA wrote:

Now as in just recently or in the patch from last year? or reaaally recently
Also, what does the refClockSyncCycles value do and is there any baseline on what to set it at?
 

github.com/linuxcnc-ethercat/linuxcnc-et...84ef36b53f0b734eaedf
the above is my patch, which I tested on real hardware, both 
refClockSyncCycles="5"
or any other positive number, this will have linuxcnc ask the slaves to sync to it every 5 cycles, put in whatever number you need to get phased in the time frame you desire, there is a dc-phased pin which tells you when you are phased, you can link that with iocontrol.0.enable-out so that you won't be able to turn on the machine till the distributed clock is properly phased.
also working
refClockSyncCycles="-1" 
or
syncToRefClock="true"
This is working with linuxcnc drifting its own phase to sync to the slaves, this is done every cycle, it is slightly more CPU intensive, as it is happening every cycle, but will phase pretty quick and works just as well in my testing.

github.com/sittner/linuxcnc-ethercat
if you are willing to do some testing of what we are building towards, you can test Sasha's current release

github.com/sittner/linuxcnc-ethercat/tre...2ea38d79aa47a58b89f7

This I believe only works well with
refClockSyncCycles="-1" 
at the moment, more testers would be appreciated, I will do my own testing of this soon.
 

andrax wrote:

Okay, thank you.

I had already thought that the issue had something to do with packet loss when starting LinuxCNC.
However, this seems to occur during operation, which I have not yet experienced. If this work results in ethercat running more stably, I will simply wait until Sascha announces an official patch, which will likely be available via update.
Until then, I will simply stick with refClockSyncCycles="1">.
 

An official release is still a few months out, the details are been worked out, still discussing and will soon get to testing on real hardware, the objective is indeed running ethercat more reliably, the current release is non-deterministic, there is nothing you can do as a user to completely get rid of the jitter noise if you have non zero CPU latency, we will hopefully find an agreeable solution for all parties, some XML settings may require changing, will try to document it all, the problems are known, now is just about finding a solution from which all can benefit.

After activation of PLL there shouldn't be any random clicks anymore.
Check dmesg if you get any errors there, it can be the network adapter too.

I could share my experience with this issue. Attached is a link to a video showing how the jitter sounds on StepperOnline A6 servos. This is exaggerated by disabling the synchronization. Once synchronization is enabled (syncToRefClock="true" or refClockSyncCycles="-1"), it still happens but much more rarely, just like grandixximo explained at the start of this post. Last week, I upgraded to the latest version of linuxcnc-ethercat, and am currently testing how the changes committed at the end of 2025 affect my machine configuration.

​​​https://imgur.com/a/FXSuvOS

Hallo,

das Linux habe ich noch nicht aufgesetzt

Allerdings habe ich gesehen, dass du meinen User im Forum auf „Deutsch“ geändert hast. Dadurch konnte ich auf dieses Thema wieder antworten:

forum.linuxcnc.org/42-deutsch/58306-umst...-erfahrunge?start=10

Vielen Dank dafür!

Bei diesem Thema bekomme ich jedoch weiterhin eine Fehlermeldung:

forum.linuxcnc.org/additive-manufacturin...drive-gesucht#343661

Könntest du das Thema eventuell wieder zurückverschieben?

Heute Abend nach der Arbeit werde ich außerdem versuchen, das Linux so aufzusetzen, wie du es beschrieben hast.

nichtAlex wrote:

Die Motoren können mit einem zusätzlichen Geber-Kabel (mit Batteriebox) mit absoluter Positionierung genutzt werden. Dadurch "merkt" sich der Motortreiber die Position auch wenn die Hauptspannung abfällt. Auch manuelle (per Hand) Bewegungen werden erfasst und beim Einschalten weiß der Motortreiber ohne Referenzieren direkt wo er genau ist. Man muss lediglich ein Mal den Nullpunkt im Treiber setzen. Habe mich damit allerdings nicht allzu viel beschäftigt.

Oh, das ist ja cool! So etwas habe ich in einem Video von Leadshine EL8 gesehen. cool das das die A6 von www.omc-stepperonline.com auch können. 

nichtAlex wrote:

Ich nutze die Motoren im inkrementalen Modus, der Treiber weiß also nicht wo der Motor steht, sondern nur wie viele Pulse er in die eine oder andere Richtung gedreht hat seit dem Einschalten. Hier ist also jedes Mal eine Referenzfahrt der Achsen erforderlich und diese mache ich über LinuxCNC in Verbindung mit einigen induktiven Näherungsschaltern.

Ah okay, Du nutzt also die Funktionen der Treiber nicht aktiv, sondern überlässt die Referenzierung weiterhin LinuxCNC.

Können grundsätzlich alle Treiber, die das CiA402-Profil (EtherCAT) unterstützen, so einfach eingebunden werden?


Wie muss ich mir das in der Praxis vorstellen – nehmen wir an, mein Aufbau wäre wie auf dem Bild dargestellt:

Sagt LinuxCNC dem Servo lediglich, welche Position angefahren werden soll, und der Treiber kümmert sich intern um die komplette Regelung?

Und was passiert, wenn ich z. B. über einen Gummipuffer Schlupf im System habe?  
Korrigiert der Treiber das selbstständig über den Encoder, weil Soll- und Ist-Position nicht übereinstimmen?  
Oder würde er in so einem Fall einen Fehler ausgeben, weil die gemessene Bewegung (Encoder) nicht zu den berechneten Schritt-/Zeitwerten passt?

Auch wenn Du geschrieben hast, dass Du Dich nicht intensiv mit den erweiterten Treiberfunktionen beschäftigt hast, frage ich trotzdem einmal in die Runde:

Der Treiber kann sich offenbar einen Home-Punkt merken und mit Batterie sogar seine absolute Position speichern – auch wenn die Anlage ausgeschaltet ist.

Wie läuft das dann beim Einschalten einer LinuxCNC-Maschine ab?  
Aktuell muss ich immer referenzieren.  

Melden die Treiber beim Einschalten ihre aktuelle Position inklusive Home-Information an LinuxCNC zurück, sodass die Maschine direkt als referenziert gilt?  
Könnte man theoretisch sofort loslegen?

Ich bekomme das gedanklich noch nicht ganz sauber zusammen.  
In meinem Kopf herrscht da gerade noch ziemliches Chaos – und ich weiß selbst noch nicht ganz, welche Fragen ich eigentlich genau stellen müsste.  
Das ärgert mich gerade ein gewaltig ?

vg Mücke 

run linuxcnc from the command line, read the error messages and try to fix them. If you can't share the message and your config here.

Short description:
Machine is equipped with integrated ethercat servosteppers, homing by Linuxcnc, not driver internally.
Every work fine but not first homing.
When I perform homing immediatelly after launch Linuxcnc I get some errors, mostly position error.
When I wait several seconds, for the DRO values changed, homing go normally.
It is my first machine with real position feedback and I have no idea what is the reason.
This is not gmoccapy problem, axis works the same.

Okay, ich muss schauen, wie das geht. Ich melde mich, wenn ich es umgesetzt habe. 

OK. one more thing we need to test, download a Linux Mint ISO, write to USB, boot the PC from that USB in Live mode, choose English as language, log in to forum and try to post.
-
Yes, there are internal logs pointing to different locale being used and the database complaining about it, hence the above request.
Danke fuhr die geduld.

Hey, 

ich habe zwar nicht die gleichen Treiber, aber ich habe einfach 5 V draufgegeben und der Treiber war gesperrt. 
Demnach müsste nur ein digitaler Ausgang deiner Mesa-Karte auf ENA+ gelegt werden und der entsprechende GND des digitalen Ports der ESA auf ENA-. 

Wenn der digitale Port dann HIGH ist, müsste der Treiber gesperrt sein. 

Gruß Mücke