Jitter > 250µs CX 1020 + AX5000

[blackhack]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus Forum

ich habe seit längerem Probleme mit Jitter über 200µs.
Es handelt sich um ein System mit 10 Servoachsen AX5000 und einer CX1020 Win CE
Die NC Task läuft auf 2ms und in den Antrieben ist eine Abweichung des Jitter von 50µs eingestellt.
Bei 10% von 2ms + den 50µs ergibt sich ein maximaler Jitter von 250µs. (Bei interpolierenden Achsen währe das vollkommen inakzeptabel)
Nun gehen meine Achsen gelegentlich in Störung wegen F415 Sync lost.
Allerdings haben wir festgestellt, dass wir beim schreiben auf das NOVRAM in der Spannungsversorgung
diesen hohen Jitter provozieren können. Nun ist das NOVRAM aber über den internen Bus mit der CPU verbunden und nicht über EtherCat. Das Problem liegt aber auf EtherCat.
Läuft die Maschine nun im Automatik Mode unterlasse ich das Schreiben und konnte somit eine Beruhigung bewirken.
Wenn man die kontinuierliche Laufzeitmessung in den Ethercateinstellungen unter Distributed Clock abwählt kann man eine Verringerung des Jitter feststellen, weil die Buslast etwas sinkt. Allerdings ist das keine Lösung, weil es nach wie vor zum Fehler kommt halt nur seltener.
Vielleicht hatte ja schon mal einer das gleiche Problem

 

[trinitaucher]

ich habe seit längerem Probleme mit Jitter über 200µs.
Es handelt sich um ein System mit 10 Servoachsen AX5000 und einer CX1020 Win CE
Die NC Task läuft auf 2ms und in den Antrieben ist eine Abweichung des Jitter von 50µs eingestellt.

Wo stellst du denn eine Abweichung des Jitters ein?

Bei 10% von 2ms + den 50µs ergibt sich ein maximaler Jitter von 250µs. (Bei interpolierenden Achsen währe das vollkommen inakzeptabel)

Verstehe die Rechnung nicht.
Wo tätigst du diese Einstellungen und mit welchen Ausgangswerten?

Nun gehen meine Achsen gelegentlich in Störung wegen F415 Sync lost.
Allerdings haben wir festgestellt, dass wir beim schreiben auf das NOVRAM in der Spannungsversorgung
diesen hohen Jitter provozieren können. Nun ist das NOVRAM aber über den internen Bus mit der CPU verbunden und nicht über EtherCat. Das Problem liegt aber auf EtherCat.

"Sync Lost" zeigt fehlende (Antriebs-seitig erwartete) Telegramme an:
http://infosys.beckhoff.com/index.p...l/ax5000_ethercat-synchronisation.htm&id=8043

Wie schreibt ihr die NOVRAM Daten? Doch hoffentlich nicht zyklisch, bzw. in einem Rutsch?
Die Kommunikation zum NOVRAM geht wohl über den internen PC104-Bus. Über den ist vermutlich auch die Ethernet-Schnittstelle angebunden. Ist der PC104 wegen des NOVRAM ausgelastet, kommen die Daten nicht mehr rechtzeitig auf den Ethernet usw.
Mein Vorschlag: NOVRAM-Daten nur in Stücken und bloß nicht jeden Zyklus schreiben.

Läuft die Maschine nun im Automatik Mode unterlasse ich das Schreiben und konnte somit eine Beruhigung bewirken.
Wenn man die kontinuierliche Laufzeitmessung in den Ethercateinstellungen unter Distributed Clock abwählt kann man eine Verringerung des Jitter feststellen, weil die Buslast etwas sinkt. Allerdings ist das keine Lösung, weil es nach wie vor zum Fehler kommt halt nur seltener.
Vielleicht hatte ja schon mal einer das gleiche Problem

Durch die Distributed Clocks läuft der Bus an sich jitterfrei, wenn das System einmal eingeregelt ist. Nur wenn die Telegramme zu spät bei den Slaves ankommen reagieren diese mit der Meldung auf verlorene Synchronistation. Die Zusammenhänge sind hier erklärt, falls du das noch nicht kennst:
http://infosys.beckhoff.com/index.p...tsystem/html/bt_ethercat_dc_intro.htm&id=5677
Den Slaves ist bekannt, wann das Telegramm vorbei kommt. Das Prozessdatenupdate findet nun eine Zeit t nach dem (vermuteten) Telegrammupdaten statt. Kommt das Telegramm nicht rechtzeitig, reagieren die Slaves mit den o. g. Fehlern. Manche tolerieren ein oder zwei verpasste Zyklen, andere steigen möglicherweise sofort aus.
Die Updatezeit kann mit der "Input-" und "Output-Shift-Zeit" ein bisschen getunt werden, falls nötig. Über die Karteireiter "DC" bei den Slaves. Aber so etwas würde ich nur mit Unterstützung durch den Beckhoff Support machen:
http://infosys.beckhoff.com/index.p...tml/bt_ethercat_dc_tcsettings_211.htm&id=5679

Ihr solltet erstmal zusehen, wodurch eure Störungen verursacht werden. Ich tippe stark auf das NOVRAM oder hohe Systemauslastung.
Überprüft mal die Prioritäten im TwinCAT und die Task-Auslastung. Gibt's da Auffälligkeiten?

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo blackhack,

was hast du für eine SPS- Zykluszeit und zu wie viel % ist diese ausgelastet?

Was zeigt die Echtzeitauslastung an?
Wie greifst du auf das NOVRAM zu?

Mein erster Verdacht ist, dass du eine hohe Auslastung hast, sporadisch längere SPS- Zyklen und eventuell eine nicht optimale EtherCAT-Synchronisation. Das geht in der Regel gut, aber von Zeit zu Zeit eben nicht.
Leider schildert der Link nur das Problem und nicht die Lösung...
Abhilfe könnte schaffen, die Zykluszeit der SPS zu verlängern - sofern möglich - und eine niederere Priorität zu wählen.
Des weiteren wäre es gut, nur sehr wenige Daten im NOVRAM zu speichern. Alle Daten sich sich nur gelegentlich ändern, können alternativ wie hier in der 2. Variante als persistent gespeichert werden.

Mein zweier Verdacht ist, dass ein Hardware- Problem vorliegt. Das kann ein schlechtes Kabel oder eine defekte Schnittstelle usw. sein.
Am schnellsten findest du diese, indem du die Ethercat-Topologie öffnest, auf Online gehst und schaust, bei welchem Teilnehmer die Crc-Fehler entstehen. Das Problem kann dann auf das Gerät vor und hinter dem Verlust eingegrenzt werden...

Viel Erfolg
Chräshe

 

[Dummy]

Hallo blackhack,

ich kenne die von Dir geschilderten Probleme.
Dazu kann ich Dir folgendes raten:

1. Arbeite mit IO am Taskanfang (Bei der NC Task ist dies die default-Einstellung)

2. Prüfe bitte ob Ihr Tasküberläufe habt!

3. Welche TwinCAT-Version verwendet Ihr?

Ab 2.11 R2 wurde die Kompensationszeit für den Task-Jitter von 10% auf 30% erhöht.
Wenn Ihr kein R2 benutz solltet Ihr auf die berechnete Outputshift sicherheitshalber 400 Mikrosekunden hinzuaddieren (siehe auch Beitrag von trinitaucher). Wenn Ihr mit Dc-Eingangsklemmen arbeitet, sollter Ihr auch die Inpushift vergößern.

Der Jitter von dem Du sprichst, ist im Übrigen der Jitter der TwinCAT-Task. Der Jitter der Uhren zueinander ist deutlich geringer.
Dieser sollte unter einer Mikrosekunde liegen (abhängig von der schnellsten Task). Die Taskzeit würde ich alllesings nicht vergrößern,
da 2ms für die meisten Servoanwendungen schon notwendig sind.

Gruß

dummy

 

[blackhack]

Wo stellst du denn eine Abweichung des Jitters ein?

im Antrieb unterm Reiter EtherCat\Erweiterte Einstellungen\Distributet Clock\ Shift Zeit\ User Defined
Den Parameter hat man mir von Beckhoff genannt und er steht default auf 50µs

Verstehe die Rechnung nicht.
Wo tätigst du diese Einstellungen und mit welchen Ausgangswerten?

in der Registry unter: \HKEY_LOCAL_MACHINE\ Software\ Beckhoff\TwinCat\System\SysPTimeExtSynchMultiplier
stehen die 10% die im Bezug auf die 2ms Taskzeit zu den 200µs führen.

"Sync Lost" zeigt fehlende (Antriebs-seitig erwartete) Telegramme an:
http://infosys.beckhoff.com/index.p...l/ax5000_ethercat-synchronisation.htm&id=8043

SynchLost sagt aus, dass das Telegramm nicht zum erwarteten Zeitpunkt am Slave war. Sollte ein Telegramm veroren oder zerstört sein kommt der Fehler 18005 Invalid Data

Wie schreibt ihr die NOVRAM Daten? Doch hoffentlich nicht zyklisch, bzw. in einem Rutsch?
Die Kommunikation zum NOVRAM geht wohl über den internen PC104-Bus. Über den ist vermutlich auch die Ethernet-Schnittstelle angebunden. Ist der PC104 wegen des NOVRAM ausgelastet, kommen die Daten nicht mehr rechtzeitig auf den Ethernet usw.
Mein Vorschlag: NOVRAM-Daten nur in Stücken und bloß nicht jeden Zyklus schreiben.

Wir schreiben bei einem event ins NovRam und das nur wenn die Anlage nicht im Automatik läuft


Durch die Distributed Clocks läuft der Bus an sich jitterfrei, wenn das System einmal eingeregelt ist. Nur wenn die Telegramme zu spät bei den Slaves ankommen reagieren diese mit der Meldung auf verlorene Synchronistation. Die Zusammenhänge sind hier erklärt, falls du das noch nicht kennst:
http://infosys.beckhoff.com/index.p...tsystem/html/bt_ethercat_dc_intro.htm&id=5677
Den Slaves ist bekannt, wann das Telegramm vorbei kommt. Das Prozessdatenupdate findet nun eine Zeit t nach dem (vermuteten) Telegrammupdaten statt. Kommt das Telegramm nicht rechtzeitig, reagieren die Slaves mit den o. g. Fehlern. Manche tolerieren ein oder zwei verpasste Zyklen, andere steigen möglicherweise sofort aus.
Die Updatezeit kann mit der "Input-" und "Output-Shift-Zeit" ein bisschen getunt werden, falls nötig. Über die Karteireiter "DC" bei den Slaves. Aber so etwas würde ich nur mit Unterstützung durch den Beckhoff Support machen:
http://infosys.beckhoff.com/index.p...tml/bt_ethercat_dc_tcsettings_211.htm&id=5679

Ihr solltet erstmal zusehen, wodurch eure Störungen verursacht werden. Ich tippe stark auf das NOVRAM oder hohe Systemauslastung.
Überprüft mal die Prioritäten im TwinCAT und die Task-Auslastung. Gibt's da Auffälligkeiten?

Hier ein Bild der Prioritätenverteilung
Die Systemauslastung liegt bei 40%
Die einzelnen Tasks haben ca 15% Auslastung

 

[blackhack]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Chräshe
Echtzeitauslastung ca40%
2 Tasks mit 2 und 10 ms Auslastung jeweils ca 15%

Aufs NovRam Schreibe ich mit FB_NovRamReadWriteEx

Persistent ist schlecht weil sich die Daten häufig ändern und dann beim Maschinenneustart wieder da sein müssen

Wir hatten das Problem an mehreren gleichen Anlagen, da liegt die Wahrscheinlichkeit eher nicht in der HW.
Dennoch hatten wir an einer Anlage an der es sehr häufig vorkam so ziemlich alles ausgetauscht.

CRC Fehler habe ich im Falle des Jitterns keine das hab ich schon nachgesehen.

Gruß Bernd

 

[blackhack]

Hallo Dummy

in der Antwort auf Chräshe habe ich die Taskanornung beigefügt, wo soll deiner Meinung nach die I/O Task liegen.

Tasküberläufe habe ich keine nur einmal beim Hochstarten.

Die TC Version auf der Maschine ist 2.10 TC CE Build 310 TC Build 1341
Am PC verwende ich die neueste 2.11.2038 von der CD 01/12

Könntest du mir noch genauer zeigen wo ich die Einstellungen:
Outputshift
Ist die Kompensationszeit für den Task-Jitter der Wert in der Registry ?
\HKEY_LOCAL_MACHINE\ Software\ Beckhoff\TwinCat\System\SysPTimeExtSynchMultiplier


Danke erstmal an trinitaucher, chräshe und dich

 

[Dummy]

Hallo blackhack!

in der Antwort auf Chräshe habe ich die Taskanornung beigefügt, wo soll deiner Meinung nach die I/O Task liegen.

Bei meiner Anmerkung ging es um die Einstellung IO am Taskanfang. Diese hat nichts mit den Prioritäten der Tasks zu tun.
Die Einstellung bewirkt, dass die Frames (Ausgangsabbild) mit dem Beginn der Task abgesendet werden und nicht nach dem der PLC-Code abgearbeitet wurde. Die Programmabarbeitungsdauer hat damit keinen Einfluss mehr auf den Sende-Zeitpunkt der Frames (höhere deterministik). Der Nachteil ist, dass sich die Reaktionszeit um einen Zyklus verlangsamt. Ist aber in der Regl immer zu verkraften.

Die Einstellung findets Du im System Manger unter SPS bzw NC Konfiguration.

Könntest du mir noch genauer zeigen wo ich die Einstellungen:
Outputshift
Ist die Kompensationszeit für den Task-Jitter der Wert in der Registry ?
\HKEY_LOCAL_MACHINE\ Software\ Beckhoff\TwinCat\System\SysPTimeExtSynchMultiplier

Die Outputshift findest Du auf dem Karteireiter des EtherCAT-Masters: Advanced Settings/Distrubuted Clocks/SYNC Shift Time for Outputs!

Der von Dir angegebene Regestry-Key hat auch einen Einfluss auf den Taskjitter. Wenn Du diesen verstellst, solltest Du sehr vorsichtig sein,
da bei falscher Einstellung die Regelung de Uhren komplett aussetzen kann. Am Besten Du änderst diesen nur in Absprache mit Beckhoff.


Gruß

dummy

 

[blackhack]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo dummy die Einstellungen in der Registry habe ich zusammen mit Beckhoff gemacht da hab ich nicht selbst rumgepfuscht Sie sagt aus um wie viel % vom Jitter das nächste Telegramm früher oder später abgeschickt wird und sorgt somit dafür das sich der Jitter mit der Zeit einregelt Richtung Null. Das kann man sich wie ein einschwingen vorstellen. Je höher der Wert um so stärker ist die Korrektur und das System schwingt über und kann sich aufschwingen. Ein zu kleiner Wert sorgt dafür das sich das System nie einschwingt und der Jitter bleibt.

Die Einstellung I/O am Taskanfang habe ich gefunden und ist bei meiner Anlage aktiviert.

Danke für deine Ausführungen.

 

[Dummy]

Hast Du den die SYNC Shift Time for Outputs auch angepasst?Ich denke damit werden sich deine Problem erledigen!Grußdummy

 

[blackhack]

Ich komme leider nicht mehr an die Anlagen, weil alle laufen.
Wenn ich wieder rankomm, werde ich es probieren.
Danke

 

[ktheb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Das Gespraech war vor 6 Jahren. Und jetzt habe ich dasselbe Problem. Blackhack, könnten Sie bitte über das Ergebnis schreiben? Hat es geklappt?

Vielen Dank und Gruss
ktheb

 

[seehma]

Falls sich hier mal wer mit TC3 durchkämpft, hier das Attribut für das jeweilige PRG im Task um das IO-Abbild am Anfang zu schreiben und lesen.
Wir hatten das selbe Problem mit Bosch Achsen, die sind hier ziemlich heikel. Obiges Attribut und bei längeren Programmlaufzeiten das verändern der Shift Zeiten hat aber geholfen.

Sg