# Welches ist der schnellste Bus?



## TerraCharly (19 Februar 2012)

Hallo,
wir verwenden bisher den Profibus an einer Mitsubishi Steuerung.
Damit läuft alles, aber es könnte schneller sein.
Ich habe einen Ausgang mit einem Eingang verbunden und erreiche damit aber nur ca. 12 Hz.
Die SPS hat eine Zykluszeit von unter 3 ms.
Wenn ich direkt Ein- und Ausgänge (von der Mitsubishi) verwende bin ich natürlich wesendlich schneller.
Welcher Bus ist schneller?
Was ist mit CC-Link?
Gibt es eine Tabelle welche die verschiedenen Bussysteme gegenüberstellt?

Hier noch einige Eckdaten:
Der Bus läuft mit 12Mbit/s
Am Bus hängen ca. 8 WAGO Profibus EA Koppler 750-323 je etwa 100 Eingänge und 50 Ausgänge
weiter 2 WAGO Profibus EA Koppler 750-333 (mit Analogsignalen) je etwa 100 dig. Eingänge und 50 Ausgänge und ein paar Analogsignale
Die verwendeten Eingänge haben eine Eingangsverzögerung von 0.2 ms (schnelle Eingänge)
2 Servo Positionierantriebe je 32 Bit EA

Bei den 12 Hz muss man berücksichtigen das pro Hz 4 Buszyklen notwendig sind.
1. Ausgang einschalten
2. Über Eingang erkennen das der Ausgang an ist
3. Ausgang ausschalten
4. Über Eingang erkennen das der Ausgang aus ist

Ausserdem habe ich nochmal nachgemessen, der Ausgang blinkt mit 13,8 Hz
d.h. der komplette Zyklus dauert 72 ms. *Was wiederum bedeutet das der Profibus 18 ms pro Vorgang benötigt.
*Wenn die Maschine ein Teil pro Sekunde produziert, und dazu 10 Komunikationsvorgänge notwendig sind,
vertrödeln wir kostbare 180 ms während wir auf den Bus warten...
das sollte besser gehen.


----------



## Mobi (20 Februar 2012)

Das schnellste m.E. ist Profinet, da es Echtzeitfähig ist.


----------



## Gerhard Bäurle (20 Februar 2012)

TerraCharly schrieb:


> ...
> Welcher Bus ist schneller?
> Was ist mit CC-Link?
> Gibt es eine Tabelle welche die verschiedenen Bussysteme gegenüberstellt?



Hallo,

den "schnellsten" Feldbus an sich gibt es so nicht.

Mit g und "Feldbus Vergleich" wirst Du verschiedene
Aussagen dazu finden.

Ethercat ist auch echtzeitfähig, wobei immer genau 
angeschaut werden muss, wie Echtzeitfähigkeit 
jeweils definiert ist.

Versuche erst mal, das bestehende System zu optimieren,
bevor Du ein anderes Bussystem oder gar eine andere 
Steuerung suchst.


----------



## Blockmove (20 Februar 2012)

12Hz entspricht 83ms..
Ich weiß nicht wieviele Busteilnehmer und welche Buseinstellungen du hast, aber solch langsame Busumlaufzeiten sind mir bei Profibus noch nicht untergekommen.

Gruß
Dieter


----------



## o.s.t. (20 Februar 2012)

läuft der Profibus mit 1.5 oder mit 12Mbit/s ?

Wobei die reine Busgeschwindigkeit nur 1 Faktor in der ganzen Geschichte ist....

o.s.t.


----------



## bike (20 Februar 2012)

Wie kommst du darauf, dass der Bus zu langsam ist?

Nur schnell ist nicht immer schneller.


bike


----------



## Lupo (20 Februar 2012)

bike schrieb:


> Wie kommst du darauf, dass der Bus zu langsam ist?
> 
> Nur schnell ist nicht immer schneller.



Das wird den Jungs heute so beigebracht. Profibus ist Out und um einiges langsamer als Ethernet. Hört sich ja auch erstmal so an : 100 MBit vs. 1,5 MBit. Das beim Ethernet dann noch eine Menge drum-herum mit übertragen und gemacht wird das berücksichtigt niemand.


----------



## Blockmove (20 Februar 2012)

Lupo schrieb:


> Das wird den Jungs heute so beigebracht. Profibus ist Out und um einiges langsamer als Ethernet. Hört sich ja auch erstmal so an : 100 MBit vs. 1,5 MBit. Das beim Ethernet dann noch eine Menge drum-herum mit übertragen und gemacht wird das berücksichtigt niemand.



Profinet ist definitiv schneller als Profibus, ABER:
Wenn es wirklich um Busgeschwindigkeit geht (im us-Bereich), dann handelt man sich aufgrund der relativ schwachen Echtzeitfähigkeit mit Profinet wohl mehr Ärger ein als mit Profibus.
Auch bei der Bus- / Netzwerkauswahl gilt der alte Grundsatz: Für jede Aufgabe das geeignete Werkzeug 

Gruß
Dieter


----------



## Mobi (20 Februar 2012)

Aber PN wird doch überall als echtzeitfähig geworben. Warum ist es denn schwach?


----------



## drfunfrock (20 Februar 2012)

Ethercat von Beckhoff ist der schnellste Bus in dem Preissegment. Das Protokoll setzt direkt auf einem IP-Frame (100Mb) auf und es gibt keine Kollisionen. Die Slaves lesen und modifizieren die Bits direkt im Frame, wenn dieses durch das Kabel läuft. Diese Geschwindigkeit bietet genug Reserven, dass selbst Profibus, CC-Link oder Interbus über Klemmen als Master funktionieren kann.

In der Regel kannst du Kommunikationszeiten von unter 100us für alle Klemmen zusammen erwarten. Zusätzlich bietet EtherCAT Zeitsynchronisation an, so dass z.B. mit fest definierten Zeitabständen ein Ausgang auf einen Eingang reagieren kann und zwar mit 1us Genauigkeit.  Oversampling von analogen Werten ist bis zu 20ns Sample-Abstand möglich.

Profibus hat aus meiner Sicht eine sehr begrenzte Kapazität.


----------



## bike (20 Februar 2012)

Mobi schrieb:


> Aber PN wird doch überall als echtzeitfähig geworben. Warum ist es denn schwach?


Was verstehst du unter Echtzeit?
Die Hardware hat in mancher Produktionsumgebung Schwächen.
Außerdem gibt es öfter Problem bei der Installation, sprich Verbindungen.




drfunfrock schrieb:


> Profibus hat aus meiner Sicht eine sehr begrenzte Kapazität.



Was willst bzw musst du über den Bus schicken?
Also Datenbankanbindung über Profibus ist eigentlich eher selten.
Zu den Abtastzeiten:
Das sind theoretische Werte. Wenn diese Zeiten erreicht werden müssen ist eine PLC die falsche Wahl.
Das ist eine Umgebung für einen Controller, das kann der besser.


bike


----------



## Mobi (20 Februar 2012)

Ist eine PLC kein Controller?? Was für Probleme gibt es denn bei den Verbindungen?


----------



## bike (20 Februar 2012)

Mobi schrieb:


> Ist eine PLC kein Controller?? Was für Probleme gibt es denn bei den Verbindungen?


PLC ist die Englisch Bezeichnung für für SPS.
Ach, den Spaß will ich nicht verderben, denn es gibt die verschiedensten Fehler.
Aber eines ist klar, jeder Anschluss und je Ader kann eins Störungsursache sein.


bike


----------



## drfunfrock (20 Februar 2012)

bike schrieb:


> Was willst bzw musst du über den Bus schicken?
> Also Datenbankanbindung über Profibus ist eigentlich eher selten.
> Zu den Abtastzeiten:
> Das sind theoretische Werte. Wenn diese Zeiten erreicht werden müssen ist eine PLC die falsche Wahl.
> ...




Ich hab einmal 6-10 RFID-Reader von Baum über Profibus ausgelesen. Ich musste auf Twincat extra einen Thread starten, weil die Datenmengen so gross waren, dass ich nicht unter 15ms Zykluszeit kam. Mit Ethercat wäre das kein Problem gewesen. Leider konnte ich nicht für jeden Reader eine Profibus-Master-Klemme kaufen. So hat das Lesen eines Tags uns mind. 200ms mehr gekostet. Das ist in ener Serienproduktion recht viel.


----------



## Mobi (20 Februar 2012)

Boah das hätte ich jetzt nicht gedacht. Und bike für Fahrrad??
Und wofür steht nun das C bzw. das S?


----------



## bike (20 Februar 2012)

drfunfrock schrieb:


> Ich hab einmal 6-10 RFID-Reader von Baum über  Profibus ausgelesen. Ich musste auf Twincat extra einen Thread starten,  weil die Datenmengen so gross waren, dass ich nicht unter 15ms  Zykluszeit kam. Mit Ethercat wäre das kein Problem gewesen. Leider  konnte ich nicht für jeden Reader eine Profibus-Master-Klemme kaufen. So  hat das Lesen eines Tags uns mind. 200ms mehr gekostet. Das ist in ener  Serienproduktion recht viel.



Also ich kenn das so oder so ähnlich.
Doch  da habe ich die Lesung über einen Interrupt gestartet, so dass nur in  der ungünstigsten Konstellation größere Zeiten aufgelaufen sind.
Denn alle Reader absolut gleichzeitig zu lesen ist eher selten.




Mobi schrieb:


> Boah das hätte ich jetzt nicht gedacht. Und bike für Fahrrad??
> Und wofür steht nun das C bzw. das S?



Der Witz war echt schwach.
http://www.mikethebike.com/

Sorry, dass ich dir Informationen zukommen lassen wollte.


bike


----------



## Oberchefe (20 Februar 2012)

Welche Eingangsklemmen werden überhaupt verwendet? Standard Digitaleingänge bei Wago haben 3ms Verzögerung weil Filterzeit, die schnellen nur 0,2.


----------



## Mobi (20 Februar 2012)

bike schrieb:


> Sorry, dass ich dir Informationen zukommen lassen wollte.
> 
> 
> bike


Kein Problem, dankeschön. Aber was ist denn nun an einem Controller anders als bei einer PLC/SPS?
Vielleicht lern ich ja nochwas dazu.


----------



## Blockmove (20 Februar 2012)

Mobi schrieb:


> Aber PN wird doch überall als echtzeitfähig geworben. Warum ist es denn schwach?



Profinet setzt auf Standard-Ethernet und IP-Protokolle auf. Aufgrund des eigentlich militärischen Ursprungs sind diese Verfahren auf möglichst hohe Ausfallsicherheit und Routingmöglichkeiten ausgelegt. Echtzeitfähigkeit war hier nie gefordert. Bei TCP/IP können sogar Pakete unterschiedliche Routen nehmen und deshalb sogar in verkehrter Reihenfolge beim Empfänger eintreffen. Der Empfänger setzt sie dann wieder eigenständig in die richtige Reihenfolge.
In der Automatisierungstechnik ist solch ein Verhalten natürlich unerwünscht. Hier sind konstante Antwort- und Reaktionszeiten wichtig. Also wird sozusagen ein Master (CPU oder CP) benötigt, der den Datenverkehr von und zu den Slaves koordiniert. Den Slaves wird mitgeteilt, wann sie was senden dürfen bezogen auf den Beginn des IO-Zyklus. Solange du ein reines Profinet innerhalb eines einizgen Subnetzes hast, ist das alles kein Problem. Hast du jetzt aber z.B. ein gemischtes Netz, was ja laut Werbung und Vertrieb gar kein Problem ist, wird es interessant. Wenn z.B. der Anlagenführer seine Urlaubsbilder auf dem Anlagendrucker ausgeben will, dann steigt die Netzlast gewaltig kann. Und jetzt ist es bei Einsatz von normalen Switchen eben vorbei mit Echtzeit.Jetzt brauchst du dann spezielle gemanagete Switche mit Priorisierung (QoS). Wenn jetzt das ganze aber über mehrere Subnetze und womöglich noch VOIP-Telefonie über das gleiche Netz laufen, dann ist es vorbei mit deterministischem Verhalten.

Gruß
Dieter

PS: Ich weiss, dass die Ausführungen sehr oberflächlich sind


----------



## drfunfrock (20 Februar 2012)

bike schrieb:


> Also ich kenn das so oder so ähnlich.
> Doch  da habe ich die Lesung über einen Interrupt gestartet, so dass nur in  der ungünstigsten Konstellation größere Zeiten aufgelaufen sind.
> Denn alle Reader absolut gleichzeitig zu lesen ist eher selten.
> 
> bike



Interrupt gibt es in TwinCAT nicht  Der Profibus wurde über eine Master-Klemme gesteuert und ich habe dann einen RFID-Tag ausgelesen, wenn ein Sensor ansprach. Trotzdem, der Mist hat zu viel Zeit gekostet.


----------



## TerraCharly (20 Februar 2012)

Wir verwenden sie schnellen Eingänge.. 0,2ms


----------



## Mobi (20 Februar 2012)

Danke Dieter für die Ausführungen. Du hast schon Recht, bei einem gemischten Netz kannst du natürlich für Echtzeitfähigkeit nicht garantieren. Wenn es um Geschwindigkeit geht, würde ich sowieso das Firmennetzt vom PN-Netz trennen, sodass nur reine PN-Geräte drin sind. Hat denn deiner Meinung nach PN eine Zukunft in der Automatisierungstechnik?


----------



## benja (20 Februar 2012)

Blockmove schrieb:


> ...
> Hast du jetzt aber z.B. ein gemischtes Netz, was ja laut Werbung und Vertrieb gar kein Problem ist, wird es interessant. Wenn z.B. der Anlagenführer seine Urlaubsbilder auf dem Anlagendrucker ausgeben will, dann steigt die Netzlast gewaltig kann. Und jetzt ist es bei Einsatz von normalen Switchen eben vorbei mit Echtzeit.Jetzt brauchst du dann spezielle gemanagete Switche mit Priorisierung (QoS). Wenn jetzt das ganze aber über mehrere Subnetze und womöglich noch VOIP-Telefonie über das gleiche Netz laufen, dann ist es vorbei mit deterministischem Verhalten.



im prinzip stimme ich dir zu. man muss aber zumindest Profinet IRT erwähnen. Wenn du eine IRT Domäne aufziehst, dann hast du Determinismus, egal wer grad meint VOIP machen zu müssen oder Urlaubsbilder zu übertragen.
Natürlich wirds dadurch nicht einfacher und erst recht nicht billiger...


----------



## Blockmove (20 Februar 2012)

Mobi schrieb:


> Danke Dieter für die Ausführungen. Du hast schon Recht, bei einem gemischten Netz kannst du natürlich für Echtzeitfähigkeit nicht garantieren. Wenn es um Geschwindigkeit geht, würde ich sowieso das Firmennetzt vom PN-Netz trennen, sodass nur reine PN-Geräte drin sind. Hat denn deiner Meinung nach PN eine Zukunft in der Automatisierungstechnik?



Klar hat PN eine Zukunft. Die Vorteile überwiegen deutlich.
Aber man darf halt - wie bei vielen anderen Dingen eben auch - nicht alles für bare Münze nehmen was einem das Marketing und der Vertrieb erzählt. Bei einem reinem PN-Netz kannst du (fast) nichts falsch machen.

Gruß
Dieter


----------



## Mobi (20 Februar 2012)

Puuh. Und ich dachte ich kann meinen Bus zu Hause wegschmeißen.^^


----------



## drfunfrock (20 Februar 2012)

PN ist nicht deterministisch oder?


----------



## TerraCharly (20 Februar 2012)

drfunfrock schrieb:


> Ethercat von Beckhoff ist der schnellste Bus in dem Preissegment. Das Protokoll setzt direkt auf einem IP-Frame (100Mb) auf und es gibt keine Kollisionen. Die Slaves lesen und modifizieren die Bits direkt im Frame, wenn dieses durch das Kabel läuft. Diese Geschwindigkeit bietet genug Reserven, dass selbst Profibus, CC-Link oder Interbus über Klemmen als Master funktionieren kann.
> 
> In der Regel kannst du Kommunikationszeiten von unter 100us für alle Klemmen zusammen erwarten. Zusätzlich bietet EtherCAT Zeitsynchronisation an, so dass z.B. mit fest definierten Zeitabständen ein Ausgang auf einen Eingang reagieren kann und zwar mit 1us Genauigkeit.  Oversampling von analogen Werten ist bis zu 20ns Sample-Abstand möglich.
> 
> Profibus hat aus meiner Sicht eine sehr begrenzte Kapazität.



*drfunfrock hat Recht.
*Ich glaube Ethercat ist eine der besten Lösungen, wenn nicht sogar die Beste.
Ich habe da noch was im Netz gefunden:
http://ethercat.at/pdf/english/Industrial_Ethernet_Technologies.pdf

Die Frage ist nun wie verbinde ich die MITSUBISHI SPS über Ethercad mit meinen IO's?
Ich finde das 750'er System von Wago (gemeinsam mit Beckhoff erntwickelt und in vielen Punkten baugleich) einfach gut.
Ethercad Buskoppler sind von Wago und natürlich auch von Beckhoff verfügbar.
Kann ich Ethernet mit Ethercad verbinden? Converter? Macht das Sinn?
oder gibt es einen Converter CC-Link IE oder SERCOS III nach Ethercad?
TerraCharly


----------



## Mobi (20 Februar 2012)

Hier zum Thema Profinet.
http://www.phoenixcontact.de/produkte/54143_54165.htm
Und Nein, ich bin nicht mehr bei Phoenix .


----------



## bike (20 Februar 2012)

TerraCharly schrieb:


> *drfunfrock hat Recht.
> *Ich glaube Ethercat ist eine der besten Lösungen, wenn nicht sogar die Beste.



Da bin ich anderer Meinung.
Für jede Anwendung muss geprüft werden, welches Bussystem das Richtige ist.
Wenn diese Entscheidung so einfach wäre, warum gibt es verschiedene Systeme?

Wobei immer noch die Frage im Raum steht: Warum muss ein Bussystem immer schneller werden?
Weil die Entwickler sich keine Gedanken mehr machen wollen oder können? 
Also wir kommen bestens ohne PN oder andere Spielereien aus.


bike


----------



## bike (20 Februar 2012)

Mobi schrieb:


> Hier zum Thema Profinet.
> http://www.phoenixcontact.de/produkte/54143_54165.htm
> Und Nein, ich bin nicht mehr bei Phoenix .



Sorry, aber soll ein System, das man einsetzt, nicht auch funktionieren?

Es ist doof für ein Produkt Werbung zu machen, wenn keine Spezifikation besteht.

So erweist  du dem Lieferanten einen Bärendienst.


bike


----------



## Gerhard Bäurle (20 Februar 2012)

drfunfrock schrieb:


> PN ist nicht deterministisch oder?



Profinet CBA nein, Profinet IO ja:

http://de.wikipedia.org/wiki/Profinet

Das ist aber mindestens so kompliziert wie es aussicht .


----------



## Mobi (20 Februar 2012)

Was funktioniert denn daran nicht? Ich dachte ihr habt kein PN.


----------



## Gerhard Bäurle (20 Februar 2012)

Mobi schrieb:


> Und Nein, ich bin nicht mehr bei Phoenix .



Frührentner oder Aussteiger?


----------



## Mobi (20 Februar 2012)

Umsteiger andere Branche


----------



## TerraCharly (20 Februar 2012)

bike schrieb:


> Da bin ich anderer Meinung.
> Für jede Anwendung muss geprüft werden, welches Bussystem das Richtige ist.
> bike


Schon richtig, natürlich müssen auch andere Eigenschaften außer der Geschwindigkeit berücksichtigt werden.
(Störsicherheit, Preis...)
Ich sehe die Sache vielleicht etwas einseitig. 
Aber kann ein Bus überhaupt ZU schnell sein?
TerraCharly


----------



## Blockmove (20 Februar 2012)

benja schrieb:


> im prinzip stimme ich dir zu. man muss aber zumindest Profinet IRT erwähnen. Wenn du eine IRT Domäne aufziehst, dann hast du Determinismus, egal wer grad meint VOIP machen zu müssen oder Urlaubsbilder zu übertragen.
> Natürlich wirds dadurch nicht einfacher und erst recht nicht billiger...



100% ACK.
IRT kann harte Echtzeit (Jitter <1µs). Allerdings brauchst du dafür spezielle Hardware (Devices und vorallem Switches).
Der Vorteil von "normalem" Profinet auf Standard-Ethernet / IP zu funktionieren ist damit dahin. Zumindest in der Praxis.
In der Theorie kann man natürlich die Cisco-Switches (oder welche auch immer) gegen Siemens Scalance tauschen.
Ich denke mal, dass da ein paar Meter zusätzliches Kupfer bzw. Glasfaser einfacher sind 

Für Antriebstechnik ist IRT aufgrund der Taktsynchronität sicher eine tolle Sache.

Gruß
Dieter


----------



## Mobi (20 Februar 2012)

Aber da muss dann auch der Geldbeutel stimmen. Aber m.E. brauchst du das nur wenn du mit Roboter hantierst. Und vorallem schnelle Abläufe hast und keine einfachen Pick-and-Place Aufgaben.


----------



## Gerhard Bäurle (20 Februar 2012)

TerraCharly schrieb:


> Aber kann ein Bus überhaupt ZU schnell sein?



Klar. Je schneller der Bus, desto größer sind die 
Auswirkungen elektromagnetischer Störungen 
(EMV). Besonders dann, wenn bei der Installation 
geschlampt wurde.


----------



## Blockmove (20 Februar 2012)

TerraCharly schrieb:


> Schon richtig, natürlich müssen auch andere Eigenschaften außer der Geschwindigkeit berücksichtigt werden.
> (Störsicherheit, Preis...)
> Ich sehe die Sache vielleicht etwas einseitig.
> Aber kann ein Bus überhaupt ZU schnell sein?
> TerraCharly



Das Problem ist ganz einfach.
3 Dinge auf einmal gibt es nur bei Kinderüberraschung 

Geschwindigkeit, Störsicherheit und Preis sind schwer unter einen Hut zu bringen.

Profinet ist hier für die meisten Anwendungen sicher ein guter Kompromis.
Du bist sehr flexibel in der Topologie.
Anschlußtechnik ist einfach (4 Adern meist auf RJ45 oder M12, keine Terminierung)
Es gibt genügend Hard- und Software für Fehlersuche und Diagnose (Netztester, Wireshark)
Breites Anwendungsspektrum von Gebäudetechnik bis hin zur Antriebstechnik.
usw.

Gruß
Dieter


----------



## Grizzly88 (20 Februar 2012)

Alles eine Definition ... Ethercat und PN sind schnell - aber nur beim richtigen Einsatz, Hardware und Konfiguration. Kommt immer auf das Vorhaben an. Meist reicht Profibus noch aus. AS-I wird auch sehr oft eingesetzt und ist nicht gerade schnell. Abzüglich den ganzen Verlusten von couplern und gateways.... Man kann auch ein Programm so schreiben, dass es die Ressourcen auffrisst oder aber den Code CPU freundlich schreiben.


----------



## drfunfrock (21 Februar 2012)

Grizzly88 schrieb:


> Alles eine Definition ... Ethercat und PN sind schnell - aber nur beim richtigen Einsatz, Hardware und Konfiguration.



Wie meinst du das? Ethercat ist einfach ein Ethernetkabel. In einfachsten Fall, aus dem nächsten PC-Shop.


----------



## Gerhard Bäurle (21 Februar 2012)

drfunfrock schrieb:


> Wie meinst du das? Ethercat ist einfach ein Ethernetkabel. In einfachsten Fall, aus dem nächsten PC-Shop.



Hallo,

so setzt man Gerüchte in die Welt ... 

Ethercat ist nur so gut bzw. so schnell, wenn ich die
passende Zusatzhardware einsetze:

http://www.beckhoff.de/EL6688/
http://www.beckhoff.de/EL6692/

M. E. verhält sich Ethercat ohne zusätzliche Hardware 
wie ein "normales" Ethernet, oder habe ich das falsch
verstanden?


----------



## bike (21 Februar 2012)

Warum in Gottes Namen wird nur gefragt wie schnell geht das?
Die Frage muss lauten: was brauch ich.

Daher ist die Frage nach dem schnellsten Bus so akademisch, dass es nervt.
Elektronen haben eine teoretische Höchstgeschwindigkeit, wenn es notwendig ist muss auf Lichtwellen umgeschaltet werden.

Muss es immer schneller sein?
Auch vor 30 Jahren konnte mam Masachinen und Anlagen programmieren die bis heute funktionieren.
Und früher war es Kupfer, das für die Funktion gesorgt hat.


bike


----------



## Longbow (21 Februar 2012)

Gerhard Bäurle schrieb:


> Hallo,
> 
> 
> 
> ...



Die oben erwähnten Klemmen sind für die "Werksübergreifende" Zeitsynchronisation notwendig.
 Ethercat setzt voraus, dass alle Geräte am Bus  Ethercat-fähig sind und kein "Nicht"-Ethercat-fähiges Gerät dazwischen quatscht, sonst ist es vorbei mit dem „Real Time“
 Es ist möglich über Bridges (die auch in einem Master sein können) normalen IP-Verkehr durchzutunneln, der wird dann in einem Ethercat-Paket "verpackt".

 Der Geschwindigkeit Vorteil von Ethercat ist Möglichkeit dass jede Klemme ihre Daten in einen Sammelframe setzen kann, damit wird der Datenoverhead reduziert.
 Damit ergeben sich bei größeren Stationen aber auch große Frames die bei elektronmagnetischen Störungen (Schütze, Motoren) sehr anfällig sind.
 Kippt ein Bit, dann sind alle Daten des Frames weg (und damit meist alle Daten des Zyklus).
 Außerdem addiert sich die Durchlaufzeit durch jede Klemme zur Gesamtdurchlaufzeit: (Zeit pro Klemme: ca. 200ns bis 700ns) Bei 1000 Klemmen ist man da schon bei 200µs Durchlaufzeit.
 Hardware:
 Master: Standard Ethernet (IEEE1588 ist von Vorteil)
 Slaves: Ethercat Chip oder IP-Core von Beckhof, Hilscher, TI... 

 Profinet als Begriff ist der Marketingname von SIEMENS darunter befinden sich:
 Profinet CBA (Kein I/O)
 Profinet I/O RT (Real Time Klasse 1 und 2 ohne Synchronisation)
 Profinet I/O IRT Flexible (Real Time Klasse 2 mit Synchronisation)
 Profinet I/O IRT High Performance oder Top (Real Time Klasse 3 mit Synchronisation und Topologie Planung)

 Mit dem Profinet Standard 2.3 (Jahr 2010) kommt dann noch
 Dynamic Frame Packing und Fast Forward hinzu (mit dieser Erweiterung möchte SIEMENS und Phoenix zu Ethercat aufschließen)

 Hardware: Master ab IRT Fähig: spezielle Chips: SIEMENS Ertec 400/200, Hilscher...
 Slave: ab IRT fähig spezielle Chips: ERTEC 200, Hilscher, Phoenix TPS1...
*Je nach Netztopologie kann Profinet IRT zusammen mit DFP schneller oder langsamer als Ethercat sein, ja nachdem wer die Studie macht.
Ein langsamer Profinet RT Master kann aber auch langsamer als ein guter PROFIBUS-Master sein!
Und die Qualität der Slave Implementierung trägt auch noch gewaltig zur „echten“ Geschwindigkeit bei.*


----------



## drfunfrock (21 Februar 2012)

Gerhard Bäurle schrieb:


> Hallo,
> 
> so setzt man Gerüchte in die Welt ...
> 
> ...



Nee, die brauchst du nicht. Die sind nur für spezielle Anwendungen da. Und weil Ethercat alles in ein Frame packt, ist dieses Protokoll effizient. Du kannst Ethercat nicht mit anderen Protokollen zusammen betreiben, aber du kannst andere Protokolle tunneln. Es gibt nichts schnelleres als Ethercat und einfach ist die Anwendung auch noch. Du brauchst einen Master, einen Buskoppler, ein Ethernet-Kabel und ein paar Klemmen. Es braucht keine Terminierung. Du brauchst dich nicht um den Bus zu kümmern, weil der in der Regel immer schneller ist, als deine SPS, solange deine Zykluszeit grösser als 100us ist und erfüllt die Kriterien für harte Echtzeit. 

Dass du dann noch Master und Slaves im Nanosek-Bereich synchronisieren kannst und dass du den Datenaustausch zwischen 2 Master so einfach gestalten kannst, indem du einfach eine Klemme dazu setzt, ist das Sahnehäubchen.


----------



## Rudi (21 Februar 2012)

bike schrieb:


> Warum in Gottes Namen wird nur gefragt wie schnell geht das?
> Muss es immer schneller sein?
> Auch vor 30 Jahren konnte mam Masachinen und Anlagen programmieren die bis heute funktionieren.
> Und früher war es Kupfer, das für die Funktion gesorgt hat.
> bike


Genau so ist das. Von uns laufen auch noch Anlagen mit programmierbaren Steuerungen die wesentlich älter als 20 Jare sind.


----------



## drfunfrock (21 Februar 2012)

Rudi schrieb:


> Genau so ist das. Von uns laufen auch noch Anlagen mit programmierbaren Steuerungen die wesentlich älter als 20 Jare sind.



Ja sie laufen. Nur vor 20 Jahren waren so Dingen wie Kode-Struktur und Pflege doch etwas schwieriger zu handhaben. Und was man früher mit uC und Interfaces gemacht hatte, weil die SPSen ungenügend waren, ist heute einfach mit einer SPS zu realisieren. Es ist keine Frage von, früher ging das auch, sondern es ist einfach Evolution und das ist gut so.


----------



## Rudi (21 Februar 2012)

Heute werden viele Steuerungen erneuert weil sie die neue Generation der Instandhalter nicht mehr kennt.


----------



## Cassandra (21 Februar 2012)

bike schrieb:


> Warum in Gottes Namen wird nur gefragt wie schnell geht das?
> Die Frage muss lauten: was brauch ich.bike


 Vermutlich hat der Themenstarter eine Anwendung, die Zeitkritisch ist.
 Wenn das schnellste auch nicht teurer ist, als etwas 20 Jahre altes von Siemens, dann suche ich mir doch nicht für jede Anwendung etwas raus, was gerade so meine Anforderungen erfüllt!



bike schrieb:


> Daher ist die Frage nach dem schnellsten Bus so akademisch, dass es nervt.
> Elektronen haben eine teoretische Höchstgeschwindigkeit, wenn es notwendig ist muss auf Lichtwellen umgeschaltet werden.


 Ja, die theoretische Höchstgeschwindigkeit ist annähernd die Lichtgeschwindigkeit. Unter normalen Bedingungen (Ohne Teilchenbeschleuniger) wird diese nie näherungsweise erreicht.  

 Bedeutet das, dass ich dann vom normalen „1GBit Ethernet“ auf  „1GBit Ethernet LWL“ umsteigen muss? 



bike schrieb:


> Muss es immer schneller sein?
> Auch vor 30 Jahren konnte mam Masachinen und Anlagen programmieren die bis heute funktionieren.
> Und früher war es Kupfer, das für die Funktion gesorgt hat.


Irgendwie habe ich das Gefühl, dass nichts was wir heute bauen, auf mehr als 5-15 Jahre ausgelegt ist. :evil:
Man stelle sich vor, Fernseher, Computer, Radios, Autos... würden so lange halten! Wir hätten wieder eine 30h Woche, weil der Markt gesättigt wäre. Mit so viel Freizeit kann doch keiner was anfangen – OK, vielleicht mehr dumme Kommentare in irgend welchen Foren zu schreiben...  

 LG Cassandra


----------



## Rudi (21 Februar 2012)

Cassandra schrieb:


> Irgendwie habe ich das Gefühl, dass nichts was wir heute bauen, auf mehr als 5-15 Jahre ausgelegt ist. :evil:
> Man stelle sich vor, Fernseher, Computer, Radios, Autos... würden so lange halten! Wir hätten wieder eine 30h Woche, weil der Markt gesättigt wäre. Mit so viel Freizeit kann doch keiner was anfangen – OK, vielleicht mehr dumme Kommentare in irgend welchen Foren zu schreiben...
> 
> LG Cassandra



Wieso WIR. Die Chinesen hätten dann mehr Freizeit.


----------



## trinitaucher (21 Februar 2012)

Vor ein Paar Jahren wurde mal der "Krieg" der Ethernet-Technologien beschworen. Zig Studien welche Technologie nun besser ist mit unterschiedlichen Ergebnisse, jenachdem wer die Studie gemacht hat.
Den "Krieg" und Schwanzvergleich hat mittlerweile aber keine Technologie mehr nötig. Denn mittlerweile entscheidet der Markt, welche Technologien eine Zukunft haben. 
(Schwanzvergleiche werden mittlerweile in der Presse hauptsächlich nur  noch aus einem Lager verbreitet, deren Technologie offensichtlich  Probleme mit der Darseinsberechtigung zu haben scheint. Sonst wären  solche Veröffentlichungen nicht notwendig)

Profinet hat seine Vorteile auf netzwerk-übergreifender Ebene. Wirkliche Performancevorteile (je nach Szenario) hat man aber nur mit IRT. Allerdings sind Produkte für IRT derzeit (immernoch) Mangelware. Keine Nachfrage? zu teuer? ... keine Ahnung
EtherCAT ist schnell. Ohne viel Aufwand und mit Standard-Komponenten i. d. R. immer schneller als die Steuerung. Außerdem zeigt's doch der Markt: Es gibt für EtherCAT zig Anbietern von Mastern, mehrere Hersteller von I/O-Systemen, und die meisten nahmhaften Hersteller von Antriebstechnik haben EtherCAT im Programm oder setzen sogar auf EtherCAT als Haupt-Feldbus.
... allein das zeigt doch schon, wo die Reise hingeht. 

Ich denke, dass EtherCAT die Technologie ist, die
a) gegenüber anderen Systemen einen wirklichen Performance-Vorteil hat und
b) vom Anwender einfach zu handhaben ist.
Topologie-unabhängige Performance, kein Netzwerkmanagement erforderlich, Diagnose bis in die Klemme (Feldebene), praktisch "Plug-and-Play".



TerraCharly schrieb:


> Ich habe da noch was im Netz gefunden:
> http://ethercat.at/pdf/english/Industrial_Ethernet_Technologies.pdf


Das ist eine schöne Gegenüberstellung der Technologien bzgl. Performance, zumindest auf I/O-Ebene


----------



## Blockmove (21 Februar 2012)

trinitaucher schrieb:


> Ich denke, dass EtherCAT die Technologie ist, die
> a) gegenüber anderen Systemen einen wirklichen Performance-Vorteil hat und
> b) vom Anwender einfach zu handhaben ist.
> Topologie-unabhängige Performance, kein Netzwerkmanagement erforderlich, Diagnose bis in die Klemme (Feldebene), praktisch "Plug-and-Play".



Bei Ethercat dürchläuft das Telegramm (Frame) jeden Teilnehmer. Jeder Teilnehmer ergänzt das Telegramm um seine Daten und schickt es weiter.
Und das ist Segen und Fluch. Zum einen ist der Aufbau und die Konfiguration dadurch einfach, zum anderen wird es dadurch störanfällig. 

Profinet (ohne IRT) setzt auf Standardprotokolle und kann daher über normale Netzwerkkomponenten geroutet werden. Diese müssen lediglich QoS und / oder VLAN unterstützen. Im Zeitalter von VOIP und Videostreaming tun dies eigentlich alle.
Für Gebäude-, Anlagen- und Fernwirktechnik ein nicht unerheblicher Vorteil.

Mein Fazit:
Wie immer im Leben: Für jede Aufgabe das richtige Werkzeug (Netz, Bus) wählen.


Gruß
Dieter


----------



## drfunfrock (22 Februar 2012)

Blockmove schrieb:


> Bei Ethercat dürchläuft das Telegramm (Frame) jeden Teilnehmer. Jeder Teilnehmer ergänzt das Telegramm um seine Daten und schickt es weiter.
> Und das ist Segen und Fluch. Zum einen ist der Aufbau und die Konfiguration dadurch einfach, zum anderen wird es dadurch störanfällig.
> 
> Profinet (ohne IRT) setzt auf Standardprotokolle und kann daher über normale Netzwerkkomponenten geroutet werden. Diese müssen lediglich QoS und / oder VLAN unterstützen. Im Zeitalter von VOIP und Videostreaming tun dies eigentlich alle.
> ...



Du vergleichst Äpfel und Birnen. :roll: Während Profinet (ohne IRT) gar keine Realtime-Anforderungen erfüllen kann, ist das mit Profibus, Interbus, Ethercat etc ohne Probleme möglich.Dann ist der Zeitbedarf Profinet (mit und ohne IRT) immer vom Protokoll-Stack der Slaves abhängig, ganz im Gegensatz zu Ethercat.  Deswegen setzt Siemens auch kein Profinet für Motioncontrol ein.  Profinet bedient ganz andere Anforderungen. Abgesehen davon, wenn jeder Slave einen eigenen Stack hat, bedeutet das auch einen potentelle Fehlerquelle, da die Implementationen nicht einheitlich sind. 

EtherCAT hat eine Ring-Struktur. Ist ein Slave gestört, wird der Ring verkürzt. Grundsätzlich ist EtherCAT nicht störanfälliger. Was wirklich nicht geht, dass EtherCAT geroutet werden kann. Dann kann man allerdings auch wieder ein anderes Protokoll nehmen, weil dann RT sowieso nicht realisiert werden kann. TCP/IP kann getunnelt werden. 

Das Routen bedeutet auch, dass du Determinismus verlierst und deshalb kann man darauf bei RT auch gerne darauf verzichten.


----------



## Longbow (22 Februar 2012)

drfunfrock schrieb:


> Du vergleichst Äpfel und Birnen. :roll: Während Profinet (ohne IRT) gar keine Realtime-Anforderungen erfüllen kann, ist das mit Profibus, Interbus, Ethercat etc ohne Probleme möglich.Dann ist der Zeitbedarf Profinet (mit und ohne IRT) immer vom Protokoll-Stack der Slaves abhängig, ganz im Gegensatz zu Ethercat.  Deswegen setzt Siemens auch kein Profinet für Motioncontrol ein.  Profinet bedient ganz andere Anforderungen. Abgesehen davon, wenn jeder Slave einen eigenen Stack hat, bedeutet das auch einen potentelle Fehlerquelle, da die Implementationen nicht einheitlich sind.
> 
> EtherCAT hat eine Ring-Struktur. Ist ein Slave gestört, wird der Ring verkürzt. Grundsätzlich ist EtherCAT nicht störanfälliger. Was wirklich nicht geht, dass EtherCAT geroutet werden kann. Dann kann man allerdings auch wieder ein anderes Protokoll nehmen, weil dann RT sowieso nicht realisiert werden kann. TCP/IP kann getunnelt werden.
> 
> Das Routen bedeutet auch, dass du Determinismus verlierst und deshalb kann man darauf bei RT auch gerne darauf verzichten.



SIEMENS setzt Profinet IRT für Motion Control ein und damit Profinet (da Profinet ohne Anhang alle Varianten abdeckt)  

Es gibt für keines der beiden Systeme eine einheitlich Implementierung. 
Bei Ethercat hängt es auch genauso wie bei Profinet von der Slave-Implementierung ab. Bei manchen Ethercat-Slaves ist es eher Softwarelastig (TI, Hilscher) oder Hardwarelastig (Beckhoff ET1100/ET1200 und IP-Cores).
 Bei Profinet gibt es Stack-technisch mehr Anbieter für die Slave-Seite als bei Ethercat aber auch eine Zertifizierung wie bei Profibus. (oder Plugfest bei Ethercat)
Für IRT gibt es momentan nur 3 Anbieter.

Bezüglich der Störanfälligkeit:
 Durch das Summenrahmenverfahren bei Ethercat reicht EIN fehlerhaftes Bit um die Daten aller Slaves dieses Frames auszulöschen.
Bei Profinet IRT (ohne DFP) wird nur der Frame des betroffenen Slaves zerstört.


----------



## trinitaucher (22 Februar 2012)

Longbow schrieb:


> Für IRT gibt es momentan nur 3 Anbieter.


Wohl auch deswegen, weil das Profinet-IRT Protokoll zwischenzeitlich geändert bzw. erweitert wurde (DFP ist ja relativ neu). Welcher Anbieter hat schon Interesse daran, möglicherweise bald "veraltete" Varianten zu implementieren.
Gibt es aktuelle IRT Devices ohne DFP? Falls ja, liegen die bestimmt wie Blei in den Regalen der Hersteller.


Longbow schrieb:


> Bezüglich der Störanfälligkeit:
> Durch das Summenrahmenverfahren bei Ethercat reicht EIN fehlerhaftes Bit um die Daten aller Slaves dieses Frames auszulöschen.
> Bei Profinet IRT (ohne DFP) wird nur der Frame des betroffenen Slaves zerstört.


Und mit DFP hat man das gleiche "Problem"?
Ich schätze in einem Profinet-IRT-Netzwerk werden entweder alle Slaves mit  oder ohne DFP betrieben. Dann hätte man entweder die Wahl zwischen schnell oder störunempfindlicher. Falls Mischbetrieb möglich ist, hat man die Schwierigkeit des Netzwerkmanagements.
Da dreht man sich im Kreis. Will man einen Performance-Vorteil, muss man IRT mit DFP nutzen. Also kann man nur die neuesten Geräte verwenden, mit dementsprechend eingeschränkter Auswahl. Aber dann ist auch die vermeintliche geringe Störempfindlichkeit dahin.

Und erst mit DFP ist IRT ansatzweise Konkurrenzfähig zu EtherCAT,  welches seit der Einführung protokolltechnisch unverändert geblieben  ist. Das erklärt m. E. das größere Vertrauen der Hersteller in die Technik und somit  die größere Produktvielfalt.
Wie bereits geschrieben, ich finde letztendlich entscheidet der Markt. Möglicherweise ist die (theoretische) Störempfindlichkeit bei EtherCAT gar kein großes Problem. Sonst würde sich EtherCAT nicht so schnell verbreiten.

übrigens:
Es gibt auch bei EtherCAT die Möglichkeit Frames aufzusplitten. Nennt sich "Sync Units" und ist zumindest mit TwinCAT sehr einfach möglich.


----------



## drfunfrock (22 Februar 2012)

Longbow schrieb:


> SIEMENS setzt Profinet IRT für Motion Control ein und damit Profinet (da Profinet ohne Anhang alle Varianten abdeckt)
> 
> Es gibt für keines der beiden Systeme eine einheitlich Implementierung.
> Bei Ethercat hängt es auch genauso wie bei Profinet von der Slave-Implementierung ab. Bei manchen Ethercat-Slaves ist es eher Softwarelastig (TI, Hilscher) oder Hardwarelastig (Beckhoff ET1100/ET1200 und IP-Cores).
> ...



Du setzt hier einige Märchen in die Welt:

1) Siemens nutzt intern für Motion-Control Drive-CLiQ (100Mbit Ethernet basierend)
2) Einen Software-Stack kann es bei EtherCAT nicht geben, weil der Frame nicht empfangen wird, sondern die Informationen aus einem Frame der vorbeizieht, geholt oder geschrieben werden. 
3) Ethercat ist RT-fähig und das ohne Rücksicht auf die Vernetzungsstruktur
4) Slaves erholen sich von einem Frameerror mit dem nächsten Frame.
5) High availability mit parallelen Kabeln und/oder redundanten Mastern ist einfach zu realisieren. 
6) Wer regelmässig Frame-Fehler hat, sollte seine Installation überprüfen. Das gilt übrigens auch für für alle anderen Protokolle.


Ich denke, dass Profinet seine Kunden finden wird, allein schon wegen der Marktposition von Siemens. Ich sehe aber kein Alleinstellungsmerkmal für Profinet.


----------



## Longbow (22 Februar 2012)

drfunfrock schrieb:


> Du setzt hier einige Märchen in die Welt:
> 
> 1) Siemens nutzt intern für Motion-Control Drive-CLiQ (100Mbit Ethernet basierend)
> 2) Einen Software-Stack kann es bei EtherCAT nicht geben, weil der Frame nicht empfangen wird, sondern die Informationen aus einem Frame der vorbeizieht, geholt oder geschrieben werden.
> ...



1) Siehe Simotion mit Profinet IRT: http://support.automation.siemens.c...lib.csinfo&lang=de&objid=49311792&caller=view
2) Sehr interessante Interpretation: Bei  jedem Ethercat-Salve wird der Frame empfangen modifiziert und wieder gesendet, allerdings sehr schnell 
    (im Bereich 200ns bis 700ns). Diese Aktion kann entweder in Hardware ausgeführt werden (ET1100/1200 oder in Software: Hilscher NetX oder TI Sitara)
3)Aber wehe es ist kein Ethercat-fähiges Gerät drin! (und immer schön single Master...)
4) Aber erst im nächsten Zyklus ohne Störung (Schon mal mit einem Ethercat-System im EMV-Burst-Test gewesen?)
5) gibt es auch bei Profinet, allerdings Stoßfrei erst mit MRPD, 
6) Diese Argumentation kommt von Beckhoff, ist allerdings für ein industrielles Umfeld nicht immer die geeignete Lösung
    SIEMENS legt an dieser Stelle mit allen ihren Produkte bezüglich der EMV-Festigkeit und der Abstrahlung eine echte hohe Latte

Dem Summary stimme ich zu: Ethercat und Profinet (und die vielen anderen Echtzeitethernetlösungen) haben immer ihre speziellen Vor- und Nachteile
Den PERFEKTEN Feldbus gibt es nicht. Aber die Marketingmaschiene von SIEMENS für Profinet könnte hier das entscheidende Element spielen.


----------



## Longbow (22 Februar 2012)

trinitaucher schrieb:


> Wohl auch deswegen, weil das Profinet-IRT Protokoll zwischenzeitlich geändert bzw. erweitert wurde (DFP ist ja relativ neu). Welcher Anbieter hat schon Interesse daran, möglicherweise bald "veraltete" Varianten zu implementieren.
> Gibt es aktuelle IRT Devices ohne DFP? Falls ja, liegen die bestimmt wie Blei in den Regalen der Hersteller.
> 
> Und mit DFP hat man das gleiche "Problem"?
> ...



Da es momentan noch kein fertiges Produkt mit DFP gibt, gibt es im wesentlichen Profinet RT oder IRT fähige Geräte.

Mit DFP hat man nicht das gleiche Probleme wie bei Ethercat, da die Daten eines Slaves innerhalb des Frames noch mal mit einer eigenen CRC abgedeckt sind. 
Ob man das nutz hängt aber von der Implementierung ab.

Bezüglich konkurenzfähigkeit IRT/Ethercat: Man kann mit Ethercat bei sehr hohen Klemmenzahlen bedingt durch die Durchlaufzeiten durch jede Klemme Szenarien aufstellen, bei denen Profinet IRT (noch ohne DFP)
schneller ist. 

Den PERFEKTEN Feldbus gibt es nicht. Aber die Marketingmaschiene von  SIEMENS für Profinet könnte hier das entscheidende Element spielen. 
Auch wenn Ethercat ein sehr gutes System darstellt (eben nur nicht PERFEKT)


----------



## drfunfrock (22 Februar 2012)

1) IRT ist nicht existent, weil das Angebot zu klein.
2) Das ist keine Interpretation, sondern eine Beschreibung der Technik und dafür taugt Software nun mal nicht, wie du vorher phantasiert hast. Die Verzögerung entsteht unweigerlich, wenn Signale detektiert werden. 
3) Ein Ethercat-Bus mit einem Nicht-EtherCAT-Gerät direkt zu koppeln ist nicht möglich. Du phantasierst.
4) EMV-Festigkeit wird immer nach den bestehenden Normen geprüft. Du solltest dich fortbilden, denn alles andere ist nicht relevant
6) Wegen 4) ist deine Bemerkung hier komplett daneben.


----------



## trinitaucher (22 Februar 2012)

Longbow schrieb:


> 3)Aber wehe es ist kein Ethercat-fähiges Gerät drin! (und immer schön single Master...)


 So ist die Systemarchitektur. EtherCAT ist per Norm ein Single-Master-System. Wer nicht-EtherCAT-Geräte in den Strang packt, tut was Verbotenes.

 Sicher wird man immer Szenarien finden, in denen mal das eine und mal das andere System schneller ist. Beim EtherCAT dauert das Update logischerweise umso länger je mehr Slaves dranhänge, dafür unabhängig von der Topologie. Bevor man aber > 10.000 Slaves an einen Master hängt, macht man lieber einen zweiten Master auf und halbiert damit wieder die Update-Zeiten ;-).

Profinet möchte nun mal jedes Szenario abdecken (Feld bis Leitebene ein Protokoll). Somit werden Kompromisse und Anforderungen an Systemarchitektur nötig, inkl. Netzwerkmanagement usw. Die mögliche Mischung von RT- und Non-RT-Frames in einem System macht die Sache nicht gerade einfacher:http://www.ethercat.org/pdf/english/Industrial_Ethernet_Technologies.pdf (Seiten 15-17 + 20/21)

EtherCAT ist für den Maschinenbau ausgelegt. Mit dem Summenrahmenverfahren auf schnelle Updateraten getrimmt und hinsichtlich Mischung von Komponenten streng limitiert. Echtzeitverkehr hat immer Vorrang, Non-RT wird nur getunnelt.
Wenn nun die Frage nach dem „schnellsten“ Feldbus lautet kann die Antwort aktuell eigentlich nur EtherCAT lauten.


----------



## Blockmove (22 Februar 2012)

trinitaucher schrieb:


> Wenn nun die Frage nach dem „schnellsten“ Feldbus lautet kann die Antwort aktuell eigentlich nur EtherCAT lauten.



Das trifft es wohl am ehesten.
Ethercat ist näher am Feldbus und Profinet ist näher am Netzwerk.


----------



## Astralavista (22 Februar 2012)

Mal eine Zwischenfrage von mir da sich hier ja doch viele damit auskennen:
Ich habe an einer Anlage eine B&R mit Ethernet Powerlink. Wie sieht es da im Vergleich zu Profinet und Ethercat aus?


----------



## drfunfrock (22 Februar 2012)

Jemand hatte hier einen Link zu einer PDF-Datei in diesem Thread gepostet, in welcher alle Bussysteme verglichen werden.


----------



## Longbow (22 Februar 2012)

drfunfrock schrieb:


> 1) IRT ist nicht existent, weil das Angebot zu klein.
> 2) Das ist keine Interpretation, sondern eine Beschreibung der Technik und dafür taugt Software nun mal nicht, wie du vorher phantasiert hast. Die Verzögerung entsteht unweigerlich, wenn Signale detektiert werden.
> 3) Ein Ethercat-Bus mit einem Nicht-EtherCAT-Gerät direkt zu koppeln ist nicht möglich. Du phantasierst.
> 4) EMV-Festigkeit wird immer nach den bestehenden Normen geprüft. Du solltest dich fortbilden, denn alles andere ist nicht relevant
> 6) Wegen 4) ist deine Bemerkung hier komplett daneben.



1)Wegen dem "kleinen Angebot" wird es auch von den größten europäischen Automobilbauern favorisiert ;-)
2)Bei Ethercat  wird der MLT3 Datenstrom durch einen der beiden Ethernet Phys in NRZ Code gewandelt, dann descrambled von 5B auf 4B Code umgesetzt und am MII Interface entweder einem ET1200(oder IP Core) von Beckhoff, einem NetX von Hilscher oder einem TI Sitara AM35xx übergeben.
Im Falle der Beckhoff Lösung erfolgt die weitere Verarbeitung in Hardware, es werden die Bits eingefügt und der CRC neu berechnet und die Daten an die 4 Bit MII Schnittstelle des anderen PHY ausgegeben um dann wieder in MLT3 Code gewandelt zu werden. Bereits relativ wenige 25 MHz(40ns) Takte nachdem das erste Nibble(4Bit) reingekommen ist, wird es auch zum anderen MII Port wieder modifiziert ausgegeben.
Bei TI Sitara AM35xx nehmen zwei 200MHz schnelle Prozessoren (PRU) die Daten vom MII Port entgegen, modifizieren die Daten und geben sie wieder aus. (Angabe TI Webseite: 700ns inklusive Phys, also ca. 300ns in den PRUs)
Bei Hilscher wird je nach NetX Version mit 3 oder 4 Prozessoren ( 1 xMAC zum Empfang, 1 oder 2  xPEC zum modifizieren, 1 xMAC zum senden) gearbeitet.

Bei den Beckhoff E-Bus Klemmen entfällt der Weg über den Phy da nicht mit MLT3 übertragen wird sondern mit 2 wertigem Manchester-Code über LVDS der direkt vom ET1100/ET1200/ESC20 entgegengenommen werden kann, dadurch reduziert sich der Durchlauf um die Phy Durchlaufzeiten.  (ca. 300ns Durchlaufzeit nach Beckhoff)



drfunfrock schrieb:


> 3) Ethercat ist RT-fähig und das ohne Rücksicht auf die Vernetzungsstruktur


Meine Antwort darauf war, dass die RTFähigkeit nur mit Ethercat-fähigen Geräten sichergestellt ist, (weil es ja gar nicht möglich ist, Nicht-Ethercat-Geräte ohne Switchport einzubinden)
So ganz ohne Rücksicht auf die Vernetzungsstruktur geht es nicht.
Profinet hat an dieser Stelle den "Fallback" auf Profinet RT (Wenn auch nicht wirklich Realtime)

4) Die EMV Prüfung nach Norm EN 61000-4-4 trifft keine Aussage über die Updaterate der Ausgänge/Eingänge während der Einstrahlung 
    Der Unterschied der Updaterate zwischen den verschiedenen Feldbusen/Systemen ist aber mit bloßem Auge erkennbar (z. B. 2KV/5kHz Burst beaufschlagt, Einspeisung am Koppler).


----------



## TerraCharly (22 Februar 2012)

trinitaucher schrieb:


> Wenn nun die Frage nach dem „schnellsten“ Feldbus lautet kann die Antwort aktuell eigentlich nur EtherCAT lauten.


Ich sehe das dank eurer Beiträge mittlerweile genau so.
DANKE an alle

Die Frage ist nun wie verbinde ich meine MITSUBISHI SPS über Ethercad mit den von uns genutzten WAGO Knoten (mit den IO's)
Ethercad Buskoppler sind von Wago verfügbar.
Mitsubishi ist Pflicht, aber die haben leider keine Ethercad Modul (noch nicht)
Kann ich Ethernet mit Ethercad verbinden? Converter? Macht das Sinn?
oder gibt es einen Converter CC-Link IE oder SERCOS III nach Ethercad?
So etwas ist sicher nicht optimal aber vielleicht besser als Profibus. 
TerraCharly


----------



## RobiHerb (22 Februar 2012)

Wenn es denn noch keiner erwähnt hat:

SERCOS II oder SERCOS III, kanallhart RT

aber nicht so billig (Bosch Rexroth), dafür aber weltweit genormt und viele Hersteller, die direkt gegeneinander austaiuschbar sind. 

Umsetzer SERCOS auf EtherCad oder aners herum ist prinzipiell nicht möglich. Das Konzept der "Distributed Clock" Synchronisation unterscheidet sich von der SERCOS Synchronisation total.


----------



## drfunfrock (23 Februar 2012)

Longbow schrieb:


> Meine Antwort darauf war, dass die RTFähigkeit nur mit Ethercat-fähigen Geräten sichergestellt ist, (weil es ja gar nicht möglich ist, Nicht-Ethercat-Geräte ohne Switchport einzubinden)



Billiges Trollen überzeugt niemanden. LOL


----------



## trinitaucher (23 Februar 2012)

Longbow schrieb:


> 1)Wegen dem "kleinen Angebot" wird es auch von den größten europäischen Automobilbauern favorisiert ;-)


Tolles Beispiel 
Wenn die Automobilbranche Siemens und Phoenix vorschreibt, erscheint das "Angebot" logischerweise groß. Und wir können uns alle ja denke nach welchen Kriterien dort manchmal entschieden wird...


----------



## bike (23 Februar 2012)

trinitaucher schrieb:


> Tolles Beispiel
> Wenn die Automobilbranche Siemens und Phoenix vorschreibt, erscheint das "Angebot" logischerweise groß. Und wir können uns alle ja denke nach welchen Kriterien dort manchmal entschieden wird...



Ja, die entscheiden was können meine Instandhalter.
Welches System ist auch ohne Studium verständlich.

Mir ist es völlig egal, was ich programmieren soll.
Wenn ich an das Danach denke, reduzieren sich die möglichen, sinnvollen Steuerungen leider sehr.

Was hilft es ein tolles System zu haben und man muss studiert haben, um es zu verstehen?

Und eines ist doch klar: Win$ wurde nie für die Automatisierung entwickelt, daher sind die darauf basierenden System nicht unbedingt Industrie tauglich.
Das ist unsere, oft leider traurige und teure, Erfahrung.


bike


----------



## benja (23 Februar 2012)

drfunfrock schrieb:


> Ich denke, dass Profinet seine Kunden finden wird, allein schon wegen der Marktposition von Siemens. Ich sehe aber kein Alleinstellungsmerkmal für Profinet.



Diagnoekonzept.
Für Fehler im Zusammenhang mit Profinet sind die standardisiert. Zum Beispiel "es ist nicht der erwartete Nachbar angeschlossen".
Das kenn ich so komfortabel nur von Profinet.
Oder Fehler im Aufbau (Beispiel statt einem 2DI Modul ist in einem IO-Device ein 2DO Modul gesteckt). Andere Systeme laufen da nicht an, bei Profinet gibts fest definiert ne Fehlermeldung über die man den Fehler sofort lokalisieren kann (sofern das Engineering des IO-Controllers das unterstützt).
Darüber hinaus kann jeder Gerötehersteller noch gerätespezifische Diagnosen (die aus seiner Applikation bzw. Geräteaufgabe kommen) definieren.
Oder wenn ein IO-Modul in einem modularen IO-Device  ausfällt. Dann hat das keine Rückwirkung auf andere IO-Devices. Nicht einmal auf die anderen Module des IO-Devices mit dem Defekt. Das wird selbst bei DFP so bleiben.

Ferner gibts noch den submodulgranularen Datenstatus (IOPS). Da muss man aber zugegebenermaßen schon mit der Lupe suchen um wirklich einen Anwendungsfall dafür zu haben. In vielen Fällen wird der nicht aktiv verwendet.


----------



## benja (23 Februar 2012)

trinitaucher schrieb:


> Tolles Beispiel
> Wenn die Automobilbranche Siemens und Phoenix vorschreibt, erscheint das "Angebot" logischerweise groß. Und wir können uns alle ja denke nach welchen Kriterien dort manchmal entschieden wird...



Mir ist neu, dass das vorgeschrieben wird. Es gibt auch andere Anbieter die im Automobil-Umfeld tätig sind und bei denen weder Siemens- noch Phoenix-Technologie im Bauch steckt.
Natürlich decken die beiden einen großen Bereich ab, speziell bei den Steuerungen knapp unter 100%, aber ob man das dem System Profinet vorwerfen kann?
Man muss halt fairerweise sagen, dass im Bereich der IO-Controller samt Engineering und Applikationsprogrammierung im Bereich Profinet Siemens und Phoenix schon die ausgereiftesten Systeme haben.


----------



## trinitaucher (24 Februar 2012)

benja schrieb:


> Diagnoekonzept.
> Für Fehler im Zusammenhang mit Profinet sind die standardisiert. Zum  Beispiel "es ist nicht der erwartete Nachbar angeschlossen".
> Das kenn ich so komfortabel nur von Profinet.
> Oder Fehler im Aufbau (Beispiel statt einem 2DI Modul ist in einem  IO-Device ein 2DO Modul gesteckt). Andere Systeme laufen da nicht an,  bei Profinet gibts fest definiert ne Fehlermeldung über die man den  Fehler sofort lokalisieren kann (sofern das Engineering des  IO-Controllers das unterstützt).
> ...


Gibt's doch beim EtherCAT genauso. Protokollseitig alles implementiert  und genormt. Hängt nur vom Master ab, wie weit die Diagnoseobjekte  ausgewertet werden.
Beim EtherCAT werden deine Beispiele mit der Diagnosemeldung "INIT VPRS" abgedeckt (vorgefundene Geräteparameter passen nicht) => weiterführend z. B. "EL3161 found, EL4132 expected" (so wird's im TwinCAT dargestellt)

Ich denke dass auch die anderen Ethernet-Systeme ähnliche Dinge implementiert haben. Nur was man halt nicht kennt ...
Ähnlich ist es mit der Fragen nach dem Kenntissen im Feld. Wenn die Instandhalter jahrelang z. B. Siemens gemacht haben und der Kunde auch hauptsächlich Siemens vorschreibt, kann man nicht erwarten, dass die bei einem anderen/neuen System auf Anhieb zu Spezialisten heranreifen und sofort die optimalsten Einstellungen oder Diagnosen finden.



benja schrieb:


> Oder wenn ein IO-Modul in einem modularen IO-Device  ausfällt. Dann hat  das keine Rückwirkung auf andere IO-Devices. Nicht einmal auf die  anderen Module des IO-Devices mit dem Defekt. Das wird selbst bei DFP so  bleiben.


Der proprietäre Rückwandbus einer I/O-Station ist nicht Teil des Feldbussystems. Das hat nichts mit Profinet zu tun, sondern mit dem jeweiligen System des Herstellers.
Was passiert, wenn ein Profinet Device mit DFP in der Mitte der Linie ausfällt? Wie erhalten die nachfolgenden Devices ihre Telegramme?



benja schrieb:


> Natürlich decken die beiden einen großen Bereich ab, speziell bei den  Steuerungen knapp unter 100%, aber ob man das dem System Profinet  vorwerfen kann?


Dann darf man bzgl. Profinet aber auch nicht das Beispiel Automobilindustrie als Beleg einer großen Vielfalt von Geräten und Herstellern heranziehen.


----------



## drfunfrock (24 Februar 2012)

Hier werden immer noch Äpfel mit Birnen verglichen. Profinet und Ethercat haben nicht unbedingt gleiche Einsatzgebiete, auch schon weil Profinet gewöhnliches TCP/IP nutzt. Und weil das Ethercat und Profinet IRT nicht machen, sind beide auch schneller und garantieren Echtzeit. Bzgl. der Standardisering von Fehlermeldungen etc., EMC-Festigkeit:

Lasst es sein, wenn ihr hier wieder Normen zitieren , noch eine Protokollanalyse vorstellen wollt. 

Und das Siemens ein Quasi-Standard in Europa ist, ist von der technischen Argumentationsseite völlig belanglos. Ich habe damals Ethercat als einer der ersten eingesetzt, weil ich 20ms Zykluszeit auf der SPS brauchte und eine Linie mit 30Prozessen gesteuert habe.

Bei anderen Aufgaben hätte ich keine Probleme andere Feldbusse zu nehmen, wenn die Anforderungen erfüllt werden und der Preis stimmt.


----------



## benja (24 Februar 2012)

trinitaucher schrieb:


> Was passiert, wenn ein Profinet Device mit DFP in der Mitte der Linie ausfällt? Wie erhalten die nachfolgenden Devices ihre Telegramme?


Ersatztelegram. Die Daten der fehlenden IO-Devices können natürlich nicht geliefert werden, aber alles was in der Linie bis zum IO-Controller noch kommt (also ab dem 1. Gerät das noch funktioniert) kann gültige Daten liefern.


----------



## trinitaucher (24 Februar 2012)

benja schrieb:


> Ersatztelegram. Die Daten der fehlenden IO-Devices können natürlich nicht geliefert werden, aber alles was in der Linie bis zum IO-Controller noch kommt (also ab dem 1. Gerät das noch funktioniert) kann gültige Daten liefern.


Siehste, ist doch bei EtherCAT genauso


----------



## hovonlo (28 Februar 2012)

drfunfrock schrieb:


> Hier werden immer noch Äpfel mit Birnen verglichen. Profinet und Ethercat haben nicht unbedingt gleiche Einsatzgebiete, auch schon weil Profinet gewöhnliches TCP/IP nutzt. Und weil das Ethercat und Profinet IRT nicht machen, sind beide auch schneller und garantieren Echtzeit.



Das ist so nicht richtig.

PROFInet kommuniziert im zyklischen Bereich NIE über IP. Dies wird allein für den Aufbau der Application Relation und azyklische Dienste verwendet.

Kurzer Überblick unter http://de.wikipedia.org/wiki/Profinet


----------



## bugatti66 (1 März 2012)

Hi,
liest der Themenstarter eigentlich noch mit?

Da war , glaube ich noch die Frage offen, ob es Sinn macht einen Konverter/Gateway/Umsetzer einzusetzen?
Das macht auf keinen Fall Sinn !
Nimm einfach den Bus, von deiner Steuerung, der schneller ist,
das ist dann auf jeden Fall Sercos, wenn du dafür die richtigen IOs findest.

Aber es kann auch sein, dass der "Haus-eigene-Bus" auch schneller ist,
da es sein kann, dass das Profibus-Modul von diesem Hersteller auch nur wie eine Art Konverter funktioniert und deswegen alles langsam macht.
Abgesehen davon, finde ich ca. 10Hz blinken für den Testaufbau gar nicht so schlecht.

P.S. Ich bin auch der Meinung Ethercat ist der schnellste, aber wir sprechen da nicht von 10 oder 20 Hz (Profibus) 
sondern 200 oder 500 Hz(Ethercat/PN-IRT/SercosIII ist eben eine andere Klasse).


----------



## TerraCharly (4 März 2012)

Danke, bugatti66
Für Sercos sind keine WAGO-IO (Pflicht) verfügbar.
Es scheint im Moment nur Profibus oder CC-Link möglich zu sein.
Ist CC-Link schneller als Profibus?
Hat jemand Erfahrungen dazu?
TerraCharly


----------



## Blockmove (4 März 2012)

TerraCharly schrieb:


> Ist CC-Link schneller als Profibus?



Beides hat RS485 und ein ähnliches Telegrammverfahren zur Basis. Da wird wohl kein allzu großer Unterschied sein.
Ich kenne deinen Aufbau und deine Einstellungen nicht, aber 18ms (wie in deinem Startbeitrag beschrieben) Buszeit sind sehr viel.
Hast du dabei mal die Schaltzeiten und der Aktualisierungszeiten der IOs angeschaut?
Die Digital-Input-Klemmen haben in der Regel Filter um Störimpulse zu unterdrücken.
Wago überträgt in den Knoten seriell zwischen den Klemmen und dem Buskoppler. Auch hierfür wird Zeit benötigt.

Gruß
Dieter


----------



## bugatti66 (12 März 2012)

Hi,
ich habe diesen Test gerade mal mit der schnellsten OMRON probiert: NJ501 und E/A: GX-MD1621
Es verhält sich so wie theoretisch auszurechnen, 
die Ausgangsausschaltzeit von 1,5ms und die feste EtherCat Buszykluszeit von 0,5ms sind dabei die bestimmenden Elemente. Ich habe eine Periodizität von 400Hz gemessen.

Wahrscheinlich kann man gute Zeiten auch mit der Kombination CJ2M und CompoNet erzielen.

Vielleicht mal über ein Wechsel der Steuerung und der E/A nachdenken?


----------



## bugatti66 (12 April 2012)

Hallo,
jetzt hatte ich mal die Gelegenheit eine CJ2M in die Finger zu bekommen,
Profibus-Master dran gemacht CJ1W-PRM21 und GRT1-PRT auf 1,5MBaud laufen lassen.
Ich war so enttäuscht vom Profibus, der macht hier bei diesem Benchmark-Test auch nur 15 Hz.
(Ausgang- und Eingangs-Ausschaltzeiten 1,5 ms, SPS-Zykluszeit 0,7ms)


----------



## rostiger Nagel (12 April 2012)

bugatti66 schrieb:


> Hallo,
> jetzt hatte ich mal die Gelegenheit eine CJ2M in die Finger zu bekommen,
> Profibus-Master dran gemacht CJ1W-PRM21 und GRT1-PRT auf 1,5MBaud laufen lassen.
> Ich war so enttäuscht vom Profibus, der macht hier bei diesem Benchmark-Test auch nur 15 Hz.
> (Ausgang- und Eingangs-Ausschaltzeiten 1,5 ms, SPS-Zykluszeit 0,7ms)



Was sind das den für Wilde Gerätschaften?


----------



## bugatti66 (12 April 2012)

Noch nie was von OMRON gehört?


----------



## Larry Laffer (12 April 2012)

Tja ... muss man wahrscheinlich nicht unbedingt ... 8)
Wenn das Ding am ProfiBus so lahm ist dann liegt das nicht am Profibus sondern an dem Slave. Ich bekomme über den Profibus von DP-Slaves (wie z.B. PB-Messverstärkern oder Servo-Reglern) problemlos alle 2 ms einen neuen Wert - also mit 500 Hz (bei 1,5 MBits).

Gruß
Larry


----------



## Longbow (12 April 2012)

bugatti66 schrieb:


> Hallo,
> jetzt hatte ich mal die Gelegenheit eine CJ2M in die Finger zu bekommen,
> Profibus-Master dran gemacht CJ1W-PRM21 und GRT1-PRT auf 1,5MBaud laufen lassen.
> Ich war so enttäuscht vom Profibus, der macht hier bei diesem Benchmark-Test auch nur 15 Hz.
> (Ausgang- und Eingangs-Ausschaltzeiten 1,5 ms, SPS-Zykluszeit 0,7ms)



Aber es liegt nicht am Profibus, sondern an der Implementierung des Masters und/oder der Anbindung an die CPU und/oder Slave.

Im Siemens Bereich erreicht man mit einem (passenden) Slave deutlich unter 1 ms  Umlaufzeit (DPV0 und DP V1). Im Taktsynchronbetrieb (DPV2: 1ms)  sind
Blinkfrequenzen von 500Hz machbar.


----------



## bugatti66 (12 April 2012)

Versuch macht klug. 
Probier es doch mal aus und zeig mir ein Foto von der Oszilloskopaufnahme, vorher glaub ich das nicht.


----------



## rostiger Nagel (12 April 2012)

Lieber Bugatti,
leider habe ich keine Erfahrung mit Omron, deshalb kenne ich auch nicht irgendwelche 
Typenbezeichnungen, ich glaube das tun die allermeisten hier nicht.  
Zu deiner Messung, die du da mit sehr fragewürdigen Baugruppen durchgeführt hast, 
lassen mich deinen Schluss, das der Profibus langsam ist, als eine blödsinnige
Behauptung hinstellen. Der Profibus ist alles andere als Langsam, gerade um ein paar
Signale schnell auszutauschen, ist der immer noch zeitgemäß und das sicherlich in 1-2ms
zu bewältigen.

Gruß RN


----------



## Longbow (12 April 2012)

bugatti66 schrieb:


> Versuch macht klug.
> Probier es doch mal aus und zeig mir ein Foto von der Oszilloskopaufnahme, vorher glaub ich das nicht.


Kommt im Laufe des sehr späten Abends ;-)


----------



## bugatti66 (12 April 2012)

Longbow schrieb:


> Kommt im Laufe des sehr späten Abends ;-)


Vielen Dank.
Nicht vergessen, nur     Ausgang mit Eingang verbinden und im Programm negieren. 
Und bitte Typenbezeichnung der verwendeten Geräte angeben.


----------



## Longbow (12 April 2012)

bugatti66 schrieb:


> Vielen Dank.
> Nicht vergessen, nur     Ausgang mit Eingang verbinden und im Programm negieren.
> Und bitte Typenbezeichnung der verwendeten Geräte angeben.



Mit Eingangsrückkopplung geht die Blinkfrequenz auf 250 Hz im Taktsynchronen Betrieb zurück, bei 1kHz Abtast/Updaterate,


----------



## bugatti66 (12 April 2012)

Ja, und dann hatte der Themenstarter auch noch einen modularen Slave benutzt (Wago) und der GRT1-PNT ist auch der Koppler eines Slice-I/O-Systems, der ja auch eine interne Zykluszeit hat, um die Daten an/von den E/As zu bringen/holen. Habt Ihr ET200?


----------



## Longbow (12 April 2012)

bugatti66 schrieb:


> Ja, und dann hatte der Themenstarter auch noch einen modularen Slave benutzt (Wago) und der GRT1-PNT ist auch der Koppler eines Slice-I/O-Systems, der ja auch eine interne Zykluszeit hat, um die Daten an/von den E/As zu bringen/holen. Habt Ihr ET200?



CPU: 414-3 PN_DP 3EM05 FW: 5.3
über Profibus DP an ET200S IM151 HF 1BA02 + 4DO HF 4BD00 + 4DI 4BD01

Im Taktsynchronen Betrieb bei 12 MBit: *      250 Hz* +-1 Hz (Screenshot)
     Taktsynchron              bei 1,5 MBit:                         *83 Hz* +- 1Hz
OB1 und Profibus frei laufend 12 MBit: *        546 Hz* +- 76 Hz  (Screenshot, hier könnte man noch etwas optimieren)
                                                                              1,5 MBit          *380 Hz* +- Toleranz nicht notiert

Screenshots am Verbindungskabel von DO nach DI






Aus Sicht von Profibus ist das noch nicht das Ende der Möglichkeiten,
aber ET200s geht ans Limit


----------

