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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmals,

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

Jogibär

von Michael J. (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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 B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Jogibär

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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