Ganz so schlimm ist es nicht ?

Ein Haus drehe ich damit nicht – aber es geht um eine Achse, auf der im Worst Case bis zu 11,5 t Achslast stehen können.
Wenn sauber verteilt wären es 5,75 t pro Rad, aber da die Lastverteilung nicht immer ideal ist, rechne ich konservativ mit ~7 t.

Der Motor selbst hat 51 Nm Nennmoment, dahinter sitzt ein 140:1 Getriebe.
Rein rechnerisch komme ich damit natürlich auf sehr hohe Haltemomente – aber das bedeutet nicht, dass ich permanent 7000 Nm fahre.

Ich habe bewusst eher „zu groß“ dimensioniert, weil:

* hohe Massenträgheit wirkt auf Motor und Getriebe
* Lastverteilung nicht konstant ist
* reproduzierbare Positionierung im mm-Bereich erforderlich ist
* Bewegung in beide Richtungen notwendig ist
* Sicherheitsreserve einkalkuliert wurde

Sollte sich im Prototyp später zeigen, dass deutlich Reserve vorhanden ist (über reale Drehmomentmessung), würde ich das System in einer späteren Ausbaustufe kleiner dimensionieren.

Was mich aktuell technisch mehr beschäftigt, ist der Drive selbst.

Wenn ich nach Servodrives schaue, finde ich fast nie eine explizite Drehzahlbegrenzung im Datenblatt.
4500 rpm sind bei mir die rechnerische Obergrenze, real erwarte ich eher 2200–3000 rpm.

Woran erkenne ich eigentlich, ob ein Drive diese Drehzahl sauber kann?

Ist das primär begrenzt durch:

* Zwischenkreisspannung / Back-EMF des Motors?
* maximale elektrische Frequenz des Drives?
* Encoder-Auswertefrequenz?
* interne Regelzykluszeit?

Oder ist bei der 400-V-Klasse eher Strom bzw. Leistung der limitierende Faktor und nicht die Drehzahl?

Falls jemand hier bereits 400-V-EtherCAT-Drives (CiA402) im Bereich 15–25 kW mit LinuxCNC (IgH + cia402.comp) im Einsatz hat, wären konkrete Erfahrungswerte sehr hilfreich.

Und ganz unabhängig davon:

Wer Interesse an dem Projekt hat – ich sitze im Großraum Stuttgart (nördlich).
Ihr seid herzlich eingeladen, auf ein Bier oder einen Tee vorbeizukommen, Euch meinen Mini-Prototypen anzuschauen und mit mir über mögliche Umsetzungen, Verbesserungen oder auch meine Denkfehler zu diskutieren.

Ich freue mich über jeden, der Lust und Zeit hat, sich das live anzusehen.

Viele Grüße
Mücke
 
 

Im Moment ist ENA bei mir auch nicht verdrahtet und die Treiber sind ständig an... mich nervt dieses Motorgefiepe wenn die Maschine nicht aktiv arbeitet. Das ist im Moment noch häufig der Fall, weil ich Einstellungen/GUI/Probe Basic teste. Ein bischen mehr Sicherheit ist ja auch ganz gut.
Danke für deine Antwort

Meine Verdrahtung nun im Anhang

Ich habe die Enable Eingänge an den Motoren einfach frei gelassen die Maschine muss (eh) "festgehalten" werden, wenn der jeweilige Motor sich nicht dreht.

Bei meinem DM860H (noname), geht der Motorstrom aus, wenn ENA+ (5V) und ENA- (GND).
Das funktioniert also prima ohne Enable, ist aber wahrscheinlich so, wie Mücke schreibt.

probably is the time to the drivers to reach the op state. in my machine i lock the enable button with the op state from the servos

Moin Mücke,
vielen Dank. Werde ich testen.

VG

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.