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
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?
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).
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
Hallo nochmals, unser Programmierer ist heute nicht da. Daher fehlen mir erstmal weitere Informationen. Jogibär
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
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.
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
Hallo, mal 2 Bilder von dem Teil. Per Drähte sind die Buchsen nicht angebunden. Jogibär
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
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.)
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...
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
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?
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
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
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
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...
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!
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.