Beckhoff und Ethercat

Realtimer

Level-1
Beiträge
16
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe schon viel über die Vorzüe und die Performance von Ethercat gelesen. Da wir für eine neue Generation von Maschinen ein schnelles Bussystem suchen, haben wir uns jetzt bei verschiedenen Unternehmen genauer informiert. Dabei haben wir erfahren, dass Ethercat zwar schnell ist, aber nicht besonders stabil laufen soll. Gibt es hier Benutzer, die etwas über Ihre Erfahrungen mit Ethercat oder anderen Echtzeit-Ethernet-Systemen (Profinte, Powerlink,..) berichten können?

LG

Realtimer
 
Hallo!
Wir haben bei uns EtherCAT in Einsatz ... ohne Probleme.
Allerdings sind alle Komponenten bei uns von Beckhoff. Wie's mit Komponenten anderer Hersteller aussieht, kann ich nicht sagen.
Anfangs hatten wir auch einige Probleme bei der Inbetriebnahme, mussten auch mal einzelne Komponenten austauschen, da sie defekt waren. Aber im Endeffekt läuft alles super. Und die Performance ist im Gegensatz zu "herkömmlichen" Feldbussen weit überlegen. Auch die Inbetriebnahme an sich (mit TwinCAT) gestaltet sich sehr einfach (Stichwort: keine Adressierung, keine Netzwerkplanung, automatisches Einlesen der Geräte/Konfiguration, etc.).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ethercat läuft absolut problemlos. Die Konfiguration ist ein Kinderspiel und man muss sich kaum um die Busszykluszeiten kümmern. Bisher sind keine Probleme aufgetreten. Es gab in der Anfangszeit vor 2-3 Jahren ein paar Probleme mit defekten Klemmen, die aber auf den Prototypenstatus zurückzuführen waren, weil wir den Kram einfach zu früh einsetzen wollten. Die Entwicklungsumgebung ist nicht an einen PC gebunden, kostet nix und ist innerhalb von 2 min installiert inkl. aller Sprachen des Standarts (ST, AWL, KOP etc). Der Kram ist hier auf einer grösseren Anlage seit 3 Jahren im Einsatz und Probleme gibt es nicht.

Das was aus meiner Sicht noch im Raum steht, inwieweit man Massnahmen zur Erdung der TCP/IP-Kabel in hoch EMC verseuchten Zonen treffen muss. Aber Beckhoff gibt ja Schulungen, die man wahrnehmen sollte, insbesondere zur Busdiagnose.
 
Das was aus meiner Sicht noch im Raum steht, inwieweit man Massnahmen zur Erdung der TCP/IP-Kabel in hoch EMC verseuchten Zonen treffen muss.

Wie meinst Du das ? Wir haben nämlich z.B. beim Schalten eines Motors sehr viele CRC-Fehler feststellen können, teilweise wechselt sogar der WC-State auf 1. Nachdem wir den Motor zerlegten, (9W, 230V) konnten wir feststellen, dass unsere ETHERCAT Relaisklemme lediglich ein 230V Printrelais schaltet, welches keinerlei Schutzbeschaltung hat. Wäre das für Dich so eine hoch EMC verseuchte Zone? Ein Problem an sich ist, das weder wir Programmierer noch die Schaltschrankbauer einen Einfuß darauf haben, was der Maschinenlieferant für ein Zeugs einbaut.
 
Wie meinst Du das ? Wir haben nämlich z.B. beim Schalten eines Motors sehr viele CRC-Fehler feststellen können, teilweise wechselt sogar der WC-State auf 1. Nachdem wir den Motor zerlegten, (9W, 230V) konnten wir feststellen, dass unsere ETHERCAT Relaisklemme lediglich ein 230V Printrelais schaltet, welches keinerlei Schutzbeschaltung hat. Wäre das für Dich so eine hoch EMC verseuchte Zone? Ein Problem an sich ist, das weder wir Programmierer noch die Schaltschrankbauer einen Einfuß darauf haben, was der Maschinenlieferant für ein Zeugs einbaut.
Dies hat nichts mit Beckhoff zu tun.

Motoren, selbst kleinmotorern, sollen nicht direkt mit relaisausgänge geschaltet werden.

:s21:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was passiert denn bei Ethercat, wenn ein Telegramm nicht ordentlich durchgekommen ist. Es kann doch nicht sein, dass ich dann für einen Echtzeitzyklus keine gültigen Daten habe. Das System, das ich aufbauen möchte, würde dann nicht funktionieren. Bitte um Aufklärung.

LG

Realtimer
 
Was meinst du mit "nicht durchkommen" ? Wird ein Telegramm manipuliert (Bit kippen), wird ein CRC-Fehler generiert und die Teilnehmer bearbeiten das Telegramm nicht weiter, es wird also verworfen. So hab ich das zumindest verstanden.
Aber bei Buszykluszeiten von unter ner Millisekunde, sollte das doch kein Problem sein, oder?
Zumal solche Fälle nicht die Regel sein dürfen, denn dann ist irgendwas mit dem Gesamtsystem nicht in Ordnung (Verkabelung etc.).
 
Im schlimmsten Falle muss man eben das Ethernetkabel wie das vom Profibus behandeln, dh. an beiden Enden erden oder in ein geerdetes und abschirmendes Rohr legen. Mit EMC-verseuchten Umgebungen meine ich so etwas wie Starkstromumgebungen etc. Aber andere Dinge sind da auch denkbar. Das muss man von Fall zu Fall entscheiden.

Einen EMC-Kurs kann ich übrigens dem Anlagenbauer nur empfehlen. Das spart viel Ärger. Auch wenn man meint, man könne es schon. Sogar manche Normen im Schiffsbau sind da nicht ganz korrekt.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was meinst du mit "nicht durchkommen" ? Wird ein Telegramm manipuliert (Bit kippen), wird ein CRC-Fehler generiert und die Teilnehmer bearbeiten das Telegramm nicht weiter, es wird also verworfen. So hab ich das zumindest verstanden.
Aber bei Buszykluszeiten von unter ner Millisekunde, sollte das doch kein Problem sein, oder?
Zumal solche Fälle nicht die Regel sein dürfen, denn dann ist irgendwas mit dem Gesamtsystem nicht in Ordnung (Verkabelung etc.).

Ich verwende doch so ein Bussystem nicht zum Spaß. Wenn ich ein Signal in Echtzeit abtasten möchte, dann mit ordentlicher Geschwindigkeit (z.B 100 μs) und vor allem zur Realisierung von digitalen Reglern. Und ich habe Anwendungen, wo ich darauf angewiesen bin, dass die Daten in jedem Zyklus gültig sind. Wo ist denn da das Echtzeitverhalten, wenn ich nicht sicher weiß, wieviel Zyklen ich benötige, bis die Daten gültig sind?

LG

Realtimer
 
Wo ist denn da das Echtzeitverhalten, wenn ich nicht sicher weiß, wieviel Zyklen ich benötige, bis die Daten gültig sind?
Busfehler sind Ausnahmen und sind für das Echtzeitverhalten nicht von Bedeutung. Bei JEDEM Bussystem sind Kommunikationsstörungen als Fehler zu werten. Nenn mir ein Bussystem, wo das anderes ist. :confused:

Bei TwinCAT gibt's sicherlich Bausteine, die dir in der SPS mitteilen, dass ein CRC-Fehler aufgetreten ist.
 
Als Konstruktuer hast du sicherzustellen, dass die Effekte von EMV nicht deine Anlage im Betrieb stören. Dazu gibt es die EMV-Zertifizierung.

Wenn du unsicher bist, hohl dir fachliche Hilfe von Beckhoff und einem EMV-Fachmann.

Zudem jeder Bus ist störanfällig und es ist nur eine Frage der Grösse der Störung. Du kannst deine Anlage nach Normen bauen, die die max. Störgrössen festlegen und das so im Verkaufsvertrag angeben und bist auf der sicheren Seite. Sollte jemand die Maschine in einer Umgebung einsetzen, die einen höheren Störpegel hat, ist es sein Pech.

Weitere Fragen zum Bus kann dir die Seite www.ethercat.org beantworten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin EMV-mäßig nicht so ganz fit...
Kann ein über Relaiskontakte geschaltetes 230V-Printrelais bereits solche Auswirkungen zur Folge haben? Ich für meinen Teil kann ja nicht jedes Gerät "zerlegen" und nachkontrollieren. Ich vermute halt, dass ein 100 MBit/s Signal wahrscheinlich anfälliger sein wird als ein Profibus mit 1MBit/s. Nicht umsonst wird uns immer gepredigt: So schnell als nötig, so langsam als möglich. Das ganze hat mich halt mal schon Nachdenken gemacht.
 
Ja, wenn wenn keine Freilaufdiode an deinem Relais geschaltet ist, ist der Effekt sogar rechtig heftig, weil die Spule ein Energiespeicher ist und diese Energie nun loswerden will. Dh. der Strom der reinfloss, will weiterfliessen. Da der Widerstand aber wegen des unterbrochenen Kontaktes hoch ist, steigt die Spannung bis die Luft ionisiert wird und ein Kanal entsteht, über den der Strom fliesst. Die EMV-Störungen dabei sind recht heftig.

Ja 100 MBit sind schnell gestört, wenn es sich um die gleiche Technologie handeln wie z.B. um RS485 würde, dh. Schirmung und elektrische Übertragung identisch sind. Das ist aber nicht der Fall.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meine Erfahrungen mit Ethercat sind eigenlich gut. Was sicher wichtig ist bei Ethercat, dass ein gutes Ethernet Kabel genommen wird. Hier sollte nicht gespart werden.

Wenn trotzdem ein Fehler passiert, kann man den Fehler Ort sehr schnell finden. Da jede Klemme ein CRC hat.

Gruss

Thomas
 
Abhängig von der Masterimplementierung und von den angeschlossenen Slaves.
Als Parameter hast du die zu übermittelnde Datenmenge, die Übertragungsrate (100 MBit/s) und die Durchlaufverzögerung pro Slave. Für letzteres nimmt man sicherheitshalber 1µs an (tatsächlich ist's angeblich weniger). Infrastrukturkomponenten (Abzweigklemmen o.Ä.) erzeugen ebenfalls eine gewisse Verzögerung.

Nen Testaufbau bei uns mit 100 (!) digitalen EtherCAT-Klemmen (50 4-Kanal Eingangs-, 50 4-Kanal Ausgangsklemmen) konnten wir mit unserem PC und TwinCAT ohne Probleme 50 µs Zykluszeit fahren.
Würde man 1µs Verzögerung pro Slave annehmen, käme man theoretisch auf 100µs allein für die Durchlaufverzögerung, was aber bei uns aber definitiv nicht der Fall war!

Im System Manager kann man sich eine Konfiguration zusammenstellen und in der E/A-Konfiguration beim EtherCAT unter der Karteikarte "EtherCAT" wird eine Vorhersage über die Zyklsuzeit getroffen ("Duration"):
http://infosys.beckhoff.com/index.p...er/reference/ethercat/html/ethercat_intro.htm
Die basiert angeblich aber nur auf allgemeinen Daten und nicht auf einer Messung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Anmerkung noch:

Ich habe eine Ethercat-Profibus-Master-Klemme in unserer Anlage und der Effekt ist, dass die CPU-Belastung erheblich gestiegen ist, jedenfalls wesentlich mehr, als wenn ich noch einmal 30 Ethercat-Klemmen
dazu genommen hätte. Die Zykluszeit ist nicht wesentlich gestiegen (Zur Zeit liegen wir noch unter 100us), aber die CPU-Belastung.

Wir haben an der selben Anlage aus historischen Gründen auch noch Interbus am laufen und das ist grausam, weil der Interbus am PC eine riesige CPU-Last erzeugt.
 
Zuletzt bearbeitet:
Zurück
Oben