Welches ist der schnellste Bus?

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 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.
Zum Vergrößern anklicken....

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
Zum Vergrößern anklicken....
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).
 
Zuletzt bearbeitet:
trinitaucher schrieb:
Wenn nun die Frage nach dem „schnellsten“ Feldbus lautet kann die Antwort aktuell eigentlich nur EtherCAT lauten.
Zum Vergrößern anklicken....
Ich sehe das dank eurer Beiträge mittlerweile genau so.:)
DANKE an alle:D

Die Frage ist nun wie verbinde ich meine MITSUBISHI SPS über Ethercad mit den von uns genutzten WAGO Knoten (mit den IO's):confused:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
trinitaucher schrieb:
Tolles Beispiel :ROFLMAO:
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... ;)
Zum Vergrößern anklicken....

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
 
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.
Zum Vergrößern anklicken....

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.
 
trinitaucher schrieb:
Tolles Beispiel :ROFLMAO:
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... ;)
Zum Vergrößern anklicken....

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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).
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.
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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?
Zum Vergrößern anklicken....
Dann darf man bzgl. Profinet aber auch nicht das Beispiel Automobilindustrie als Beleg einer großen Vielfalt von Geräten und Herstellern heranziehen.
 
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.
 
trinitaucher schrieb:
Was passiert, wenn ein Profinet Device mit DFP in der Mitte der Linie ausfällt? Wie erhalten die nachfolgenden Devices ihre Telegramme?
Zum Vergrößern anklicken....
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
Zum Vergrößern anklicken....
Siehste, ist doch bei EtherCAT genauso :cool:
 
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.
Zum Vergrößern anklicken....

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
 
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).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
TerraCharly schrieb:
Ist CC-Link schneller als Profibus?
Zum Vergrößern anklicken....

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
 
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?
 
Zuletzt bearbeitet:

Similar threads

X
Step 7 Verarbeitung von schnellen Signalen ( ca. 1-2ms )
2
Antworten
20
Aufrufe
6K
Xplosion
X
A
[BIETE] AS-i- und Profibus-Module (Ventile, E/A), Netzteil 24V DC
Antworten
0
Aufrufe
4K
ANMA
A
Perfektionist
wie schnell ist die Prozessdatenübertragung über einen CP 342-5 von/zur CPU 319?
Antworten
5
Aufrufe
4K
godi
godi
Zurück
Oben