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. 

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 

Wie zu erwatren ist ein Fehler aufgetreten  

Error
Kunena Internal Error: Please contact the site administrator to fix this issue!

 Ist eventuell etwas intern mitgeloggt worden? 

 

Dec 27 it looks like from github. Actually, the bug shouldn't affect you.
A negative refClockSyncCycles value should switch on the PLL and synchronize servo loop time with DC time.
You can always check the lcec.pll-* hal variables. If some of them move, it's on.
refClockSyncCycles is how often the master sends a synchronization signal to the slaves to compensate for clock drift.
I use 1000 because the slaves' DC clock run pretty accurate as it is. Many people use 1 as value.
I have not seen that any number is better than the other, maybe there is, but feel free to use any number you prefer.



 

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?

There was a bug with "-1", fixed now but it sounds like you have it.
Use a positive value in refClockSyncCycles and set syncToRefClock="true"
and that should hopefully fix it.

I currently have refClockSyncCycles="-1" which according to the docs you linked above, means its enabled for backwards compatibility. Sadly, I have these mentioned issues where the axis starts clunking randomly (on a random axis) after some time. Its a fresh install from end of january. Does SyncToRefClock still need to be set?

Better yet, enable synchronization with syncToRefClock="true"
github.com/linuxcnc-ethercat/linuxcnc-et...s.md#master-settings

The refClockSyncCycles is how often to synchronize the clocks between the slaves
which is something different altogether, and doesn't help this problem.

Never mind.