Forum: Mikrocontroller und Digitale Elektronik EtherCat - PHY Enhanced Link Detection


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael J. (jogibaer)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe mal eine Frage an die Ethercat Spezialisten.

Wir haben Probleme mit Ethercat Busmodulen.
Dies sind bis zu 120 Module, die hintereinander in Reihe geschaltet 
sind.
Laut Hersteller kein Problem.
Diese befinden sich alle in mehreren angereihten Schaltschränken.

Dort gehen sporadisch Module bis zu ca. 20 Mal am Tag auf Störung.
Die Störung ist immer Verbindungsverlust.
Es sind oft die gleichen Module, aber nach Tausch der Module und der
Verbindungskabel sind die Probleme an diesem Modul weg (aber nicht 
immer)
und plötzlich andere Module betroffen, die bisher keine Probleme 
machten.

Eine externe Firma hat EMV Messungen durchgeführt, aber keine Probleme 
mit
EMV oder dem Potentialausgleich gefunden.
Die Verkabelung ist auch OK.

Verschiedene Kabel (CAT6) von diversen Markenherstellern haben auch 
nicht wirklich zu einer Verbesserung geführt, aber manchmal sind die 
Probleme geringer geworden.

Wir verdächtigen ein wenig , das der Link zwischen 2 Geräten 
zusammenbricht, das Modul erkennt dies und sendet direkt über den 
Rückkanal
zum Master zurück. Dieser meldet dann einen Verbindungsverlust zwischen 
2 Modulen. Nach einem Softwarereset des EtherCats läuft es zu 95% 
wieder.

So wie ich mich eingelesen habe, wird der Link von den PHY in den 
Modulen mehr oder weniger unter sich ausgehandelt  und der Link wird 
regelmäßig überprüft: https://de.wikipedia.org/wiki/Autonegotiation

In der Hardware der Module ist als PHY ein DP83849 verbaut.
Dazu findet sich in der

>>>
Application Note
Ethercat Slave Controller
PHY Selection Guide
von Beckhoff
<<<

der Hinweis, daß die Enhanced Link Detection (ELD) benutzt werden muß.
(siehe Anhang)

In der :

>>>>
Application Note
Ethercat Slave Controller
Application Note PHY Selection Guide
von Beckhoff
<<<<

Finden sich die beiden anderen Anhänge zur ELD.

Leider steht mir überhaupt keine Doku über das Ethercat Modul zur
Verfügung und wie ich vermute, werde ich die auch nicht bekommen.
Und beim Hersteller nachfragen, na ja.
Wir sind auch schon länger mit diesem in Verbindung, aber das Problem
konnte bisher nicht gelöst werden.

Darum erst mal die grundsätzliche Frage:

Können unsere Probleme darauf zurückzuführen sein, daß die ELD nicht 
genutzt wird?
Hat jemand damit schon mal ähnliche Probleme gehabt?
Oder wo kann noch die Ursache liegen?

Mit der Hoffnung auf verwertbare Hinweise

Jogibär

von Bernd (Gast)


Lesenswert?

Michael J. schrieb:
> Dort gehen sporadisch Module bis zu ca. 20 Mal am Tag auf Störung.
> Die Störung ist immer Verbindungsverlust.
> Es sind oft die gleichen Module, aber nach Tausch der Module und der
> Verbindungskabel sind die Probleme an diesem Modul weg (aber nicht
> immer)
> und plötzlich andere Module betroffen, die bisher keine Probleme
> machten.
So einer Art Heisenbug.
Das klingt für mich, als wenn da was prinzipiell am Limit läuft.


> Können unsere Probleme darauf zurückzuführen sein, daß die ELD nicht
> genutzt wird?
Kann sein, aber eigentlich sollte sich so ein Ethernet-Link nicht 
einfach verabschieden. Wenn ich das richtig lese, sorgt die ELD nur 
dafür, das der sich der Link schnell wieder aufbaut. Damit wird das 
Symptom beseitigt, aber nicht die Ursache.

Ich würde die Module auf zwei Teilketten aufteilen und schauen, ob es 
damit klappt.

Welche Zykluszeit wird momentan genutzt?

von Jim M. (turboj)


Lesenswert?

Michael J. schrieb:
> Eine externe Firma hat EMV Messungen durchgeführt, aber keine Probleme
> mit
> EMV oder dem Potentialausgleich gefunden.

Das ist es bei Ethernet meistens nicht, da nur selten UTP Kabel 
verwendet werden.

> Die Verkabelung ist auch OK.

Womit und wie gemessen?

Ich frage das, weil mich das schwerstens an Probleme mit "falsche 
Verdrillung des Kabels" erinnert. Kann passieren wenn man mit den Farben 
beim Auflegen nicht aufpasst.

Bei Ethernet müssen ja die "richtigen" Drähte miteinander verdrillt 
sein.

Daher ist "Durchgangsmessung" nicht ausreichend, und man muss HF messen 
(=teuer).

von Michael J. (Gast)


Lesenswert?

Hallo,

die verwendeten Kabel sind fertige Patchkabel.
Durchgemessen wurden die Kabel mit dem Meßgerät Fluke DSX600,
was diverse Parameter ermittelt.
Meßergebnis : OK

Jogibär

von Michael J. (Gast)


Lesenswert?

Hallo nochmals,

unser Programmierer ist heute nicht da.
Daher fehlen mir erstmal weitere Informationen.

Jogibär

von Michael J. (Gast)


Lesenswert?

Hallo Bernd,

nach Rücksprache mit unserem Programmierer benutzen
wir eine Zykluszeit von 5ms.
Allerdings ist das fast alles was wir einstellen können.
Der Ethercat Controller ist mehr oder weniger eine Black Box.
Wir senden per Profinet unsere Daten hin und dann legt der Controller 
los.

Auch die Diagnoseinfomationen sind sehr spärlich.
Viel kann man damit nicht anfangen.



Jogibär

von Bernd (Gast)


Lesenswert?

Das DSX600 sieht für Netzwerkkabel ganz brauchbar aus.
(Wenn man die Messergebnisse interpretieren kann.)


Michael J. schrieb:
> nach Rücksprache mit unserem Programmierer benutzen
> wir eine Zykluszeit von 5ms.

Laut den folgenden Dokumenten sollte selbst bei über 100 Slaves 
wesentlich höhere Zykluszeiten möglich sein:
https://www.ethercat.org/pdf/english/ETFA_2008_EtherCAT_vs_PROFINET_IRT.pdf
https://en.wikipedia.org/wiki/EtherCAT#Performance

Dagegen sind eure 5 ms richtig langsam, sollten also kein Problem 
darstellen. Ich würde trotzdem den Bus halbieren und schauen, ob sich 
das Problem halbiert oder in einer Hälfte bleibt.

von Alex E. (tecnologic) Benutzerseite


Lesenswert?

Habt ihr Mal geprüft wie das EtherCat vom Anschluss (M12/RJ45) an den 
phy angebunden ist. Hab da schon so lustige Sachen wie fliegende nicht 
verstellte Drähte die an einen 2mm Molex Steckverbinder gingen. Wenn man 
das korrigierte liegen die Module Jahre lang durch.

: Bearbeitet durch User
von Michael J. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

mal 2 Bilder von dem Teil.
Per Drähte sind die Buchsen nicht angebunden.

Jogibär

von Alex E. (tecnologic) Benutzerseite


Lesenswert?

Ok das sieht sehr gut aus. Könnte natürlich noch sein das der 
Schaltregler daneben was stört aber das Layout sieht von außen so aus 
das der Layouter wusste was er tat. Kannst du dich mit Wireshark Mal in 
den EtherCat hängen, dann bekommst du ggf. Ein genaueres Fehler Bild.

Hier Mal ne Recht schöne Anleitung von kollmorgen

https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.kollmorgen.com/sites/default/files/How%2520to%2520capture%2520and%2520use%2520WireShark%2520trace%2520data%2520with%2520EtherCAT%2520applications.pdf&ved=2ahUKEwiXtLnNiJHkAhXGepoKHUbUCH8QFjABegQIBRAB&usg=AOvVaw3XbQObeebe1_vVBm7ah3lc&cshid=1566291210014

von foobar (Gast)


Lesenswert?

Keine Erfahrung mit EtherCat, aber hast du mal unshielded Kabel 
verwendet?  Nicht dass da Ausgleichsströme über den Mantel fließen ...


.oO(Da machen die Designer von Ethernet nen großen Aufwand um eine 
galvanische Trennung zu erreichen und der Wahn nach "besseren" Kabel 
macht das im Handumdrehen kaputt.)

von Bernd (Gast)


Lesenswert?

Michael J. schrieb:
> Dort gehen sporadisch Module bis zu ca. 20 Mal am Tag auf Störung.
> Die Störung ist immer Verbindungsverlust.
Geht nur ein Modul in Störung oder ist dann gleich der restliche Bus mit 
weg, bzw. die Module die hinter dem gestörten Modul hängen?
Trotz Kettenschaltung wird bei EtherCat ja logisch ein Ring gebildet...

von Michael J. (jogibaer)


Lesenswert?

Bernd schrieb:
> Michael J. schrieb:
>> Dort gehen sporadisch Module bis zu ca. 20 Mal am Tag auf Störung.
>> Die Störung ist immer Verbindungsverlust.
> Geht nur ein Modul in Störung oder ist dann gleich der restliche Bus mit
> weg, bzw. die Module die hinter dem gestörten Modul hängen?
> Trotz Kettenschaltung wird bei EtherCat ja logisch ein Ring gebildet...

Hallo,

das Gerät, welches kein nachfolgendes Gerät detektiert, (weil es das 
letzte ist oder die Verbindung gestört ist) schickt seine Pakete zurück 
zum Master.

Wenn jetzt zwischen 2 Geräten der Link zusammenbricht, bekommen die 
nachfolgenden Geräte keine Daten mehr und melden daraufhin Timeout.
Diese sind dadurch natürlich auch gestört, aber nicht daran Schuld.

Jogibär

von Bernd (Gast)


Lesenswert?

Michael J. schrieb:
> Wenn jetzt zwischen 2 Geräten der Link zusammenbricht, bekommen die
> nachfolgenden Geräte keine Daten mehr und melden daraufhin Timeout.
Wenn die Verbindung gestört ist, kannst Du den Timeout eigentlich gar 
nicht sehen?!?

Michael J. schrieb:
> bis zu 120 Module
...
> sporadisch
Wie sieht die Stromversorgung aus? Bekommen die Module ihre 24 V aus der 
selben Versorgung oder ist in jedem Schrank eine?

von Michael J. (Gast)


Lesenswert?

Hallo,

wenn der Ethercat Bus neu gestartet ist, dann steht in den Logs der 
Geräte,
die nachfolgend die Verbindung verloren haben,der vorherige Timeout.

Die Geräte haben in jedem Schrank eine eigene Spannungsversorgung per 
24VDC
aus einem Industrienetzteil.
Die 24VDC Zuführung haben wir mehrmals geändert bzw.soweit wie es ging
verbessert.
Es trat keine Verbesserung bzw. Verschlechterung der Fehler auf.

Wir haben außerdem jede Menge anderer Geräte mit Profinet bzw. Ethernet
in den Schränken mit dem gleichen Kabeltyp im Einsatz.
Diese Bussysteme arbeiten fehlerfrei!


Jogibär

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Michael J. schrieb:
> mit dem gleichen Kabeltyp im Einsatz.
Sind die Module irgendwelchen Erschütterungen/Bewegungen ausgesetzt?

Michael J. schrieb:
> nach Tausch ... der Verbindungskabel sind die Probleme an diesem Modul weg
Wir hatten in der Funktionsmodellphase bei der Einführung von EtherCAT 
mit unseren eigenen und mit zugekauften EtherCAT Modulen immer wieder 
Probleme und Verbindungssbrüche.
Irgendwann kam der Verdacht auf Kontaktprobleme in der RJ45 
Steckverbindung. Ich habe das dann genauer untersucht 
(Übergangswiderstände nach mehrmaligem Stecken, seitliche Kraft auf den 
Stecker, usw...) und musste erst mal den richtigen Stecker zur richtigen 
Buchse finden und dann das richtige Kabel (Dätwyler 5502flex) dazu 
nehmen. Jetzt werden unsere Kabel nach unseren Spezifikationen 
konfektioniert und seither ist absolute Ruhe. So wie ich das sehe, ist 
das Flexkabel der eigentliche Knackpunkt, weil es weniger Kraft und 
Vibrationen auf den Steckkontakt leitet.

Mit beliebigen fertigen Kabeln "von der Stange" gibt es selbst auf dem 
Labortisch immer wieder seltsame Effekte. Irgendwer berührt irgendwo 
irgendwas und schon hakelt es mal wieder.

: Bearbeitet durch Moderator
von Thore B. (titus)


Lesenswert?

Hallo Jogibär,

zwei Jahre später und zumindest bei uns noch aktuell. Wir haben gerade 
ein sehr ähnliches Fehlerbild und bisher keine Lösung.

Bei uns sind ca. 90 EtherCAT Slaves aktiv und auch hier haben wir 
sporadisch bis zu 30 Fehler an einem Tag, zwischendurch jedoch auch 
viele Tage kein Fehler. Wir verlieren dabei auch jeweils den Link 
zwischen zwei Antrieben. Tauschen wir das Kabel, tritt der Fehler 
erstmal nicht mehr auf, jedoch häufig kurze Zeit später an einer anderen 
Stelle.

Auch wir waren schon mit einer externe Firma auf der Suche nach EMV und 
Potentialunterschieden.

Daher bin ich sehr interessiert ob du mittlerweile eine Lösung für 
dieses Fehlerbild gefunden hast?

Viele Grüße

von Experte (Gast)


Lesenswert?

Thore B. schrieb:
> Bei uns sind ca. 90 EtherCAT Slaves aktiv und auch hier haben wir
> sporadisch bis zu 30 Fehler an einem Tag, zwischendurch jedoch auch
> viele Tage kein Fehler. Wir verlieren dabei auch jeweils den Link
> zwischen zwei Antrieben. Tauschen wir das Kabel, tritt der Fehler
> erstmal nicht mehr auf, jedoch häufig kurze Zeit später an einer anderen
> Stelle.

Witzig, oder gar nicht witzig.

Auch wir haben vereinzelt Anlagen in Betrieb, bei denen wir diese 
Link-Abbrüche haben. Kabel und Verdrahtung haben wird durch, das ist es 
wohl nicht.

Persönlich habe ich inzwischen eher den Verdacht, dass es ein 
Software- und/oder Firmware-Problem ist. Meine Vermutung geht in die 
Richtung, dass die Slave-Controller bei bestimmten Bedingungen kurz 
blockiert/überlastet sind, und deshalb die Verbindung zusammenbricht. 
Aber was da genau passiert, keine Ahnung...

Bekchoff ist wie immer, keine Hilfe. Man ist immer "der Erste" der so 
ein Problem hätte. Kotzt mich inzwischen richtig an...

von Experte (Gast)


Lesenswert?

Zusatzfrage: Was für Antriebe?

von Michael J. (jogibaer)


Lesenswert?

Hallo,

bei der Menge von Geräten und dem Problem kommt mir das sehr bekannt 
vor.
Leider haben wir nie die wirkliche Ursache finden können.
Diese kann auf der Hardwareseite liegen oder auf der Softwareseite.
Der Hersteller hat sich auch widersprochen.
Mal hieß es, der Ethercat Stack war eingekauft,
mal das wäre eine Eigenentwicklung.
Dann wurden Untersuchungen versprochen, die nicht erfolgt sind.

Die Unterstützung vom Hersteller war nicht gut.
Er hat sich zwar bemüht, aber man hat gemerkt,
das er wahrscheinlich überfordert war.
Es wirkte wie blinder Aktionismus.
Wir haben zwar ständig Logs hingesendet, aber die Antworten waren
eigentlich unbrauchbar.

Wir haben zum Schluß uns von allen Patchkabellieferanten
im Industriebereich Muster besorgt und dann die Kabel genommen, die am
wenigsten Probleme machen.
Seitdem läuft es einigermaßen akzeptabel.

Ich bin allerdings nicht der Meinung, daß es an den Kabeln liegt.
Ethercat ist eigentlich Ethernet, welches sogar das IP Protokoll 
benutzt,
die Daten aber on the Fly im Datenstrom direkt manipuliert und nicht 
erst
verarbeitet und dann weiterleitet.
Ich vermute, daß das Kabel irgendwo besser ist als andere und damit eine
andere schlechte Stelle in der gesamten Kette kompensiert.
Damit sieht es so aus, als ob das Kabel für die Probleme verantwortlich 
ist.

Wer mal auf einer LAN Party war und irgendwelches Zeugs zusammengesteckt
hat und dann lief alles stundenlang problemlos durch, dann kann man
seine Zweifel bekommen.

Eines der Probleme ist meines Erachtens die Firmware.
Im Prinzip sagt diese als Diagnose nur -> es geht oder nicht.
Keinerlei Hinweise auf die Ursache z.B.

Linkverlust,
CRC Fehler,
ungültiges Datendiagramm,
Timeout

Dann könnte man was eingrenzen.
Aber wie gesagt, nicht bei diesen Geräten des Hersteller.
Am Ende blieb nur noch Frust.

Es kommt mir so vor, als ob die Firmware wegen eines Ereignisses
abstürzt. Von mir aus ein gekipptes Bit oder ähnliches.
Normalerweise kein Problem.
Denn obwohl das Telegramm hunderte Mal wiederholt wurde, war
das Gerät nicht mehr erreichbar und mußte resetet werden.

Es tut mir leid, daß ich Dir nicht anders weiterhelfen kann, aber
so ist leider der aktuelle Stand.
Zum Glück haben wir ein neues Problem und es kann passieren, daß wir uns
zum großen Teil von diesem Hersteller verabschieden.

Jogibär

PS:
Von der Hardware gibt es keinen Unterschied zu Ethernet oder Profinet.
Diese Busse laufen in unseren Anlagen wirklich problemlos.
Egal welche Stecker und welche Kabel!

von Michael J. (jogibaer)


Lesenswert?

Experte schrieb:

> Persönlich habe ich inzwischen eher den Verdacht, dass es ein
> Software- und/oder Firmware-Problem ist. Meine Vermutung geht in die
> Richtung, dass die Slave-Controller bei bestimmten Bedingungen kurz
> blockiert/überlastet sind, und deshalb die Verbindung zusammenbricht.
> Aber was da genau passiert, keine Ahnung...
>
> Bekchoff ist wie immer, keine Hilfe. Man ist immer "der Erste" der so
> ein Problem hätte. Kotzt mich inzwischen richtig an...

Hallo,

das ist auch mein Verdacht.
Interessant ist, das Beckhoff als "Erfinder" vom Ethercat betroffen ist.
Die werden wohl ihre eigene Firmware nutzen.
Leider stecke ich nicht so tief drin, aber könnte es auch eine
Designschwäche des Ethercat Protokolls sein?
Oder alle anderen Hersteller setzen irgendwie auf den Beckhoff Stack.


Jogibär

PS: Bei uns waren FUs betroffen, Servos vom gleichen Hersteller
seltsamerweise nicht.

: Bearbeitet durch User
von Michael J. (jogibaer)


Lesenswert?

Experte schrieb:

> Bekchoff ist wie immer, keine Hilfe. Man ist immer "der Erste" der so
> ein Problem hätte. Kotzt mich inzwischen richtig an...

Wurde uns von unserem Hersteller auch erzählt.
Bis wir mitbekommen haben, daß auch andere Kunden betroffen sind.

Naja, Lügen ist ja eine der wichtigsten Säulen unsere
Industrie geworden...

Jogibär

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.