# Ethercat Problem



## PLCUser (8 April 2011)

Ich habe so alle paar Tage mal einen Ausfall am Ethercat und habe da schon was von sogenannten "lost frame" gehört. Kennt jemand dieses Problem bzw. wie kann ich das abstellen.
Bin für jede Antwort dankbar.


----------



## OBS (8 April 2011)

bin selbst kein user von ethercat. habe aber auch schon mal von diesen Problemen gehört. möglicherweise emv-probleme?


----------



## Chräshe (8 April 2011)

Hallo PLCUser,

das Stichwort das du benötigst ist EtherCAT-Topologie. Du kannst im System-Manager die Topologie deiner Steuerung einsehen. Wenn du dann Online gehst, werden die Fehler und auch die „verlorenen Rahmen“ angezeigt. 

Im Normalfall gibt es keine Übertragungsverluste. Wenn doch, dann liegt definitiv ein Problem vor. Ich kann mich erinnern, dass es vor ein paar Jahren mal „problematische“ EtherCAT-Kabel für die Feldverkabelung gab. 

Auf alle Fälle solltest du den State jeder Klemme auswerten. (State = 8 → Alles OK)
Es hat sich sehr bewährt, den State auch in der VISU darzustellen. Dann kann der Elektriker ohne PG sofort lokalisieren, wo die Verbindung gestört ist...

Gruß
Chräshe


----------



## PLCUser (11 April 2011)

Das hab ich alles schon gemacht und ich glaube das es im Normalfall auch Störungen gibt sonst bräuchte man keine Checksumme oder ?

Verwende zur Verbindung Harting Industriekabel, die meiner Meinung nach sehr gut aussehen und habe diese auch schon getauscht.
Es bleibt beim alten alle 2-3 Tage Tage.

Was passiert eigentlich wenn so eine Übertragung schief geht ?
Ist das System Fehlertollerant ?


----------



## Chräshe (11 April 2011)

PLCUser schrieb:


> Das hab ich alles schon gemacht und ich glaube das  es im Normalfall auch Störungen gibt sonst bräuchte man keine  Checksumme oder ?
> 
> Verwende zur Verbindung Harting Industriekabel, die meiner Meinung nach sehr gut aussehen und habe diese auch schon getauscht.
> Es bleibt beim alten alle 2-3 Tage Tage.
> ...



Hallo PLCUser,  

nein, eine Störung ist nicht der Normalfall, sondern ein Störfall...

Was hast du schon alles gemacht?
Wenn du Online gehst, siehst du wie viele verlorene Pakete sich aufsummiert haben. Im Normalfall sollten die 4 Zähler möglichst „0“ sein. Ebenso siehst du den Status der markierten Klemme (wird zudem Farbig dargestellt).

Wenn eine Übertragung fehlerhaft ist, werden die Daten verworfen und die nächste Übertagung gestartet. Wenn zu viele Übertragungen in Folge, oder zu viele Übertagungen pro Zeit verloren gehen, steigt der Bus aus. Was im einzelnen geschieht kann man selbst noch festlegen (Fehlerreaktion). Das kann man alles in dem Handbuch nachlesen, welches im Moment erst geschrieben wird... :s12:

Kleiner Tipp: Baue ein kleines Netzwerk mit 3-4 EtherCAT Boxen oder Koppler auf. Wenn du dann online geht und mal die Versorgungs-Spannung, mal die Busverbindung wegnimmst, kannst du schön beobachten, was passiert...

Gruß
Chräshe


----------



## PLCUser (12 April 2011)

d.h. man geht davon aus das nichts gestört wird oder ?
Ich glaub ich wart da lieber auf das Handbuch.
Mir ist schon bewußt das in 99,99% alles gut geht,
aber das gibt ja dann auch unvorhersehbare Effekte oder ?,
z.b. bei Latchfunktionen


----------



## Chräshe (17 April 2011)

PLCUser schrieb:


> d.h. man geht davon aus das nichts gestört wird oder ?
> Ich glaub ich wart da lieber auf das Handbuch.
> Mir ist schon bewußt das in 99,99% alles gut geht,
> aber das gibt ja dann auch unvorhersehbare Effekte oder ?,
> z.b. bei Latchfunktionen



Hallo PLCUser, 

wenn du in dein Auto steigt, gehst du auch davon aus, dass du nicht in einen schweren Unfall verwickelt wirst.

 Dass das Handbuch in mehren Themen Lücken aufweist, finde ich auch nicht so toll. Aber so kritisch ist das nicht.  

Bei einer Übertragungsstörung wird der Fehler in der Regel erkannt und die Daten werden neu angefordert. Wenn zu viele Übertragungen in Folge, oder zu viele Übertagungen pro Zeit verloren gehen, steigt der Bus aus. Es kann passieren, dass dann alle SPS- Ausgänge „0“ werden (Voreinstellung).  

Sofern du den State jedes EtherCAT- Teilnehmers auswertest, kannst du genau feststellen, wo das Problem aufgetreten ist.

Gruß
Chräshe


----------



## PLCUser (18 April 2011)

Das Auto ist ein Superbeispiel und natürlich gehe ich nicht davon aus das ich einen Unfall habe, aber mann weiß aus Erfahrung es kracht statistisch alle 250.000 km. 

Jetzt zu meinem Problem, wenns "kracht" , muß ich was tun oder nicht ?
Muß ich mir überlegen ob meine Servos austrudeln oder nicht ?
Hab ich noch eine Chance überhaupt was zu tun ?
Mein Problem ist kann ich den Sonderfall ignorieren oder nicht ?

Im Auto setzt zumindest das ABS bzw. das ASR ein und zuletzt auch der Airbag und die Gurtstraffer, ohne das ich mir was überlegen muß dabei oder ? 

mfg Paul


----------



## Dummy (18 April 2011)

PLCUser schrieb:


> Das Auto ist ein Superbeispiel und natürlich gehe ich nicht davon aus das ich einen Unfall habe, aber mann weiß aus Erfahrung es kracht statistisch alle 250.000 km.
> 
> Jetzt zu meinem Problem, wenns "kracht" , muß ich was tun oder nicht ?
> Muß ich mir überlegen ob meine Servos austrudeln oder nicht ?
> ...


 
Hallo Paul,

Du hast recht, es kommt ab und an zu Telegrammausfällen am EtherCAT.
Dies sollte aber sehr selten vorkommen und dann sollte auch nur ein Telegramm ausfallen. Also nicht mehrere hintereinander.

Du solltest Dir eine EtherCAT-Diagnose bauen, die den EtherCAT überwacht und dann entsprechend für deine Applikation reagieren.
Deine Servoantriebe sollten im Übrigen bei zwei aufeinander folgenden Lost-Frames selbständig reagieren und an ihrer Notstopprampe zum Stehen kommen. Dies gilt zumindest laut Norm für SOE-Antriebe (Servo/Sercos over EtherCAT).
Ich habe auch schon gehört, dass Hersteller anders reagieren.
Du solltest Dich da mit deinem Antriebssystem vertraut machen.


Gruß

dummy


----------



## Dummy (18 April 2011)

Chräshe schrieb:


> Hallo PLCUser,
> 
> wenn du in dein Auto steigt, gehst du auch davon aus, dass du nicht in einen schweren Unfall verwickelt wirst.
> 
> ...


 
Hallo Chräshe,

der EtherCAT kennt keine Telegramm-Wiederholung bei Störung. 
Die Daten aus dem Zyklus sind leider verloren.
Ist leider bei allen Ethernet basierten Feldbusen so.

Gruß
dumy


----------



## Chräshe (18 April 2011)

@dumy: Oh, habe ich das mit Ethernet verwechselt..!?  
Danke für die Info, man lernt nie aus. Ich werde die Doku künftig wieder etwas sorgfältiger lesen, sofern vorhanden... 

 @Paul: Anscheinend waren deine Bedenken doch nicht ganz unbegründet... 
 Ganz Wasserdicht hört sich die Formulierung aus dem Info-Sys nicht an:




> http://infosys.beckhoff.de/...
> „Idealerweise findet die Link-Erkennung und damit das Port-Handling im ESC so schnell statt, dass selbst bei 100 µs Zykluszeit kein Lost-Frame-Ereignis auftritt. *Dennoch ist zumindest ein verlorener Frame nie auszuschließen,* falls nämlich eine Verbindung getrennt wird, während ein Ethernet-Frame gerade genau auf diesem Kabel bzw. in dem Bussegment hinter der Trennstelle unterwegs ist.“


Aber zumindest konnte ich keine „Lost- Frames“ mehr beobachten, seit die „schlechten“ Kabel ausgetauscht sind.

 Gruß
Chräshe


----------



## maddin (19 April 2011)

Hallo PLCUser,
den Schwerpunkt deiner Fehlersuche nicht nur auf die Leitungen beschränken. Wir hatten auch schon schlechte Kontakte in einem Busstecker (Wackler durch Drahtbruch -> ganz gemein :sc6: ) und sogar fehlerhafte Teilnehmer, deren Ethercat Schnittstelle noch nicht ausgereift war. Sollte man auch beachten. Verlorene Frames gibt es ab und an schon, aber eine Busstörung löst dies nicht aus, da muss eine Teilnehmer schon längere Zeit keine Antwort geben (können).
Such erst mal auf der Hardwareseite. Schau dir mal deine Topologie an. Wenn mehrere Teilnehmer verlorene Frames zählen, dann fang beim ersten dieser Teilnehmer an zu suchen.

Gruß Maddin


----------



## PLCUser (20 April 2011)

Ich habe da Servos mit im System, könnte es nicht ein EMV Problem sein ?
Kommt einmal am Tag bis einmal die Woche vor.

Die Servos Takten mit 16Khz (also allle 62,5 us) und beschleunigen und bremsen dauernd. Werde trotzdem nochmal Config überprüfen und Kabel prüfen.
Und ich habe es mir schon gedacht das es keinen Retry gibt sondern erst beim nächsten Buszyklus wieder was passiert.

"Also man geht nicht von einem Unfall aus "


----------



## trinitaucher (23 April 2011)

PLCUser schrieb:


> Ich habe da Servos mit im System, könnte es nicht ein EMV Problem sein ?
> Kommt einmal am Tag bis einmal die Woche vor.
> 
> Die Servos Takten mit 16Khz (also allle 62,5 us) und beschleunigen und bremsen dauernd. Werde trotzdem nochmal Config überprüfen und Kabel prüfen.
> ...


Wie kritisch ist denn nun der Telegrammausfll bei dir?

1. Woran erkennst du die Telegrammausfälle?
 => Steigen Slaves aus (Antriebe bleiben mit Fehler stehen) oder siehst du lediglich, dass die Counter für "Lost Frames" und/oder "Tx/Rx Errors" hochgezählt sind, wenn du von Zeit zu Zeit mal nachschaust?

2. Wie häufig passieren die Telegrammausfälle?
 => minütlich, stündlich, täglich, wöchentlich

3. Wie kritisch sind Telegrammausfälle für die Applikation?
Wenn nur die Counter hochzählen, aber die Applikation nicht beeinträchtigt wird, würde ich es beobachten, aber jetzt erst einmal keinen akuten Handlungsbedarf sehen.
Wenn öfters Antriebe aussteigen, oder du Messapplikationen machst, wo es auf jeden Zyklus ankommt, muss auf jeden Fall gehandelt werden.

Wie ist in deinem Programm die Feldbusanalyse ausgestaltet?
Du kannst über die PLC alles vom EtherCAT-Master auswerten (benutzt du überhaupt TwinCAT?).
Der Slave Status bringt dir nur was, wenn der Slave schon ausgestiegen ist. Besser ist der "Working Counter" (WcState). Der zeigt an, ob die Prozessdaten des Slaves gültig sind. Du kannst so ganz einfach ermitteln, ob ein "Lost Frame" auch zu ungültigen Prozessdaten führt. Falls nicht, ist es erst einmal nicht sooo kritisch. Normalerweise toleriert das TwinCAT den Ausfall eines Zyklus. Denn im nächsten werden die Daten wieder aktualisiert.


----------

