# Ethernet Powerlink / Profinet Feld Erfahrungen



## FG-HH (12 Februar 2007)

Hallo zusammen,

hat jemand Erfahrung mit Ethernet Powerlink Systemen (speziell B&R X20 System)? Wie ist die Erfahrung mit dem Support von B&R und der Teileverfügbarkeit (weltweit)?
Wie sieht es mit der Verbereitung von Powerlink im Vergleich zu Profinet aus? Gibt es eine Empfehlung aus Benutzersicht (Pro und Contra Profinet / Powerlink)?
Ich würde mich über entsprechendes Feedback sehr freuen.

MfG

FG


----------



## Maxl (12 Februar 2007)

Also ich kann über EPL (Ethernet Powerlink) eigentlich nur gutes vermelden. Von der Verbreitung her dürfte EPL derzeit sogar vor Profinet liegen, da EPL doch schon einige Jahre verfügbar ist.

Lenze, KEB usw. haben auf der Nürnberg-Messe bereits ihr EPL-Anschaltungen präsentiert, SEW will auf der Hannover-Messe (Aussage SEW von letzter Woche) nachziehen.

EPL hat gegenüber Profinet einige entscheidende Unterschiede:
- Profinet basiert auf Standard-Ethernet und kann auch mit diesem gemischt werden, für echtzeitfähigen Profinet-Strecken müssen jedoch Switches eingesetzt werden, die Qos (Quality of Servis) unterstützen. Man ist hier also auf einige wenige Typen von Siemens, Phönix und Hirschmann beschränkt; abgesehen sind alle (mir bisher bekannten) Komponenten teurer als die gleichwertigen Profibus-Komponenten.
- EPL hat nur auf der Physikalischen Seite (Kabel usw.) etwas mit Ethernet zu zun - von Protokoll her ist es eher mit CanOpen und DeviceNet verwandt. Es vereint die Vorteile von diesen Bussystemen mit der Verkabelung und Geschwindigkeit von Ethernet. Eine Mischung mit Standard-Ethernet ist nur mit speziellen Gateways möglich, dafür sind allerdings keine speziellen Switches notwendig.

Vom Konzept her ist derzeit EPL mein Favorit unter den Ethernet-basierten Bussystemen, da es die Feldebene und die Leitebene klar trennt (B&R-CPUs haben üblicherweise á 1 Standard-Ethernet und 1 EPL-Schnittstelle). EPL ist nicht teurer als z.B. CAN oder Profibus.

Die entscheidenden Vorteile von EPL gegenüber Profinet sind die kürzere Zykluszeit und die Möglichkeit, EPL+X20 taktsynchron zu SPS-Taskklassen zu betreiben (ohne spezielle Baugruppen).


Bei uns sind derzeit 2 EPL-Systeme im Einsatz (12 Acopos + 1 X20, 1 x X20 alleine). Bisher sind keine Probleme aufgetreten.
Das Thema Profinet ist bei uns vorerst vom Tisch, da es gegenüber Profibus kaum Vorteile bringt - und vor die echtzeittaugliche bzw. sicherheitsgerichtete Kopplung zwischen 2 CPUs erst recht wieder PN/PN-Koppler notwendig sind.

X20 kann im Notfall auch über Profibus (schon verfügbar) bzw. Profinet (ab Mitte/Ende 2007) an eine S7-Steuerung angebunden werden.

Die Teileverfügbarkeit, vor allem in Asien und Südamerika, ist bei B&R und Siemens gleich schlecht. Ich habe 2 Kunden in China (Nähe Hongkong), die sämtliche Siemens-Ersatzteile bei uns ordern, da die Wartezeiten kürzer sind, als wenn sie bei einer Siemens-Niederlassung in China bestellen.


Solltest Du noch Fragen haben, nur zu.


mfg
Maxl


----------



## Fx64 (14 Februar 2007)

Hallo FG-HH,

vielleicht ist noch eine Alternative interessant; welce gerade in Bezug auf Leistung, Verfügbarkeit und Verbreitung beide vorher genannten in den Schatten stellen dürfte...

www.beckhoff.de/german/ethercat/default.htm 

oder

http://www.ethercat.org/

oder 

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

Viele Grüsse


----------



## trinitaucher (15 Februar 2007)

@ FG-HH:
Für welche Zwecke soll denn das System eingesetzt werden?
Denn Profinet, Powerlink und EtherCAT haben alle ihre speziellen Anwendungsfällt, wo es Stärken und Schwächen der Systeme gibt.

Ich habe schon mit EtherCAT und Profinet gearbeitet. Profinet hat mich nicht so sehr überzeugt, mag aber seine Stärken in der unternehmensweiten Vernetzung haben. Die Konfiguration ist für meine Begriffe aber umständlich. Zudem sollen (angeblich) die Anschaltkosten recht hoch sein.
EtherCAT zeigt seine Stärken, wenn es um schnellen I/O-Datentransfer geht. Da schlägt es Profinet um Längen. Auch, da selbst eine einfache, modulare digitale I/O-Klemme EtherCAT beherrschen kann, also ein Rückwandbus entfällt.
Für die anderen Systeme braucht man aufgrund der Kommunikationsstruktur immer Koppler mit Rückwandbus (auf der I/O-Ebene).
EtherCAT arbeitet zudem Tasksynchron.

Die Updatezeit von Powerlink ist angeblich stark abhängig von der Anzahl der Teilnehmer durch die Kommunikation mit Zeitschlitzen. Hat jemand ein Paar Werte zur Hand ?


----------



## Maxl (15 Februar 2007)

trinitaucher schrieb:


> Profinet hat mich nicht so sehr überzeugt, mag aber seine Stärken in der unternehmensweiten Vernetzung haben. Die Konfiguration ist für meine Begriffe aber umständlich. Zudem sollen (angeblich) die Anschaltkosten recht hoch sein.


Ich kenne zwar Ethercat zu wenig, aber gegenüber Profibus und EPL ist Profinet definitiv teurer.


trinitaucher schrieb:


> EtherCAT zeigt seine Stärken, wenn es um schnellen I/O-Datentransfer geht. Da schlägt es Profinet um Längen. Auch, da selbst eine einfache, modulare digitale I/O-Klemme EtherCAT beherrschen kann, also ein Rückwandbus entfällt.Für die anderen Systeme braucht man aufgrund der Kommunikationsstruktur immer Koppler mit Rückwandbus (auf der I/O-Ebene).


Bei den Buskoppler-Preisen für EPL [z.B. €83 für X20) finde ich das nicht tragisch. Zudem bin ich der Meinung, dass sich ein Rückwandbus immer noch günstiger in eine Klemme implementieren lässt, als Ethernet. Von daher gefällt mir das X2X-System von B&R nicht schlecht, welches zu EPL synchron arbeiten kann, und sowohl als X20-Rückwandbus als auch als Feldbus verwenden lässt. Muss aber dazusagen, dass ich mich noch nicht mit EtherCat beschäftigt habe.


trinitaucher schrieb:


> EtherCAT arbeitet zudem Tasksynchron.


Profinet kann durch den Einsatz von IRT-Switches Taktsynchron arbeiten (teuer -> sehr teuer). EPL arbeitet von vornherein Taktsynchron.



trinitaucher schrieb:


> Die Updatezeit von Powerlink ist angeblich stark abhängig von der Anzahl der Teilnehmer durch die Kommunikation mit Zeitschlitzen. Hat jemand ein Paar Werte zur Hand ?


Das ist korrekt. Bei EPL teilen sich alle Busteilnehmer die Bandbreite von 100 MBit/s (Token-Bus). Daher wird auch die Reaktionszeit mit zunehmender Anzahl Teilnehmer größer. Für I/Os hab ich keine Werte zur Hand, jedoch gibt B&R bei 50 Acopos-Achsen + 50 I/O-Knoten eine Reaktionszeit von 2.5 ms an. Ich hab ein CNC-System mit 12 Achsen im Haus, dieses Arbeitet mit 800µs Takt - wobei hier aber die CPU an ihre Grenzen stößt - Inwieweit der EPL hier noch Reserven hat, weiß ich nicht.


Um auf die ursprüngliche Frage zurückzukommen:
Beim objektiven Vergleich Ethernet Powerlink zu Profinet liegt EPL klar vorne.


mfg
Maxl

PS: Beim objektiven Vergleich von allen Ethernet-basierten Feldbussystemen liegt Profinet klar an letzter Stelle!!


----------



## trinitaucher (15 Februar 2007)

Maxl schrieb:


> trinitaucher schrieb:
> 
> 
> 
> ...


Bei EtherCAT meine ich wirklich *Task*-Synchron. Also ETC braucht immer eine sog. "Trigger-Task", z.B. ein SPS- oder CNC-Programm. Soll heißen, ein Daten-Zyklus ist praktisch bestenfalls so schnell wie die schnellste Task, zumindest im Rahmen der Nutzung mit TwinCAT. Kann die deterministische Abarbeitung der Task garantiert werden (mit geringem Jitter), arbeitet ETC auch synchron dazu. Zur wirklichen Teilnemersynchronisation gibt's das Konzept der "verteilten Uhren".
Die Telegramm-Umlaufzeiten sind jedoch um längen schneller. Unsere Teststation (2 Digital-Klemmen (EL1../EL2..) + 2 Analog-Klemmen (EL3../EL4..) + Profibus-Master (EL6731) + Switch-Klemme (EL6601)) kommt auf Latenzzeiten von ca. *10 µs*, wobei dieser Wert mit der Anzahl der am Profibus angeschlossenen Slaves steigt (weil dann mehr Prozessdatenwörter zu übertragen sind).
Allerdings weiß ich nicht, wie's aussieht, wenn T(Telegramm-Latenz) > T(Task-Zyklus) ist.


----------



## FG-HH (16 Februar 2007)

trinitaucher schrieb:


> @ FG-HH:
> Für welche Zwecke soll denn das System eingesetzt werden?
> Denn Profinet, Powerlink und EtherCAT haben alle ihre speziellen Anwendungsfällt, wo es Stärken und Schwächen der Systeme gibt.
> 
> ...


----------



## Ralle (16 Februar 2007)

*0,05 msek. Raster

*Das wird wohl nicht alles über einen Bus gehen, würde ich mal vermuten, das sind 50 Mikrosekunden, das haben manche Controller schon Probleme. ICh glaube die externe Lösung läßt sich da nicht umgehen, oder?*
*


----------



## Maxl (17 Februar 2007)

FG-HH schrieb:


> trinitaucher schrieb:
> 
> 
> > Um auf die Frage zum Einsatz zurück zu kommen. Wir wollen die Steuerung inkl. Bussystem für eine "normal Maschinensteuerung" einsetzen. Kritischster Punkt in der Anwendung ist, an bis zu 60 Analogdatenpunkten (16Bit Messwerte) in einem 0,05 msek. Raster aufzuzeichnen und auszuwerten (0,05 msek Raster stimmt!).
> ...


----------



## trinitaucher (17 Februar 2007)

@ FG-HH:
EtherCAT in Verbindung mit ner Soft-SPS dürfte die 50 µs zu schaffen sein!

Die Trigger-Task müsste dann mit 50 µs Zykluszeit realisiert werden und die Telegrammverzögerung über den EtherCAT sollte unter 40 µs liegen. Es gibt von Beckhoff EtherCAT-AI-Klemmen, die 50 µs Wandlungszeit haben, z.B. die EL3162 (2-Kanal AI 0..10V, 16 Bit). Zweikanalige Klemmen haben ne höhere Wandlungszeit, aber es kann durch abschalten eines Kanals die Wandlungszeit verringert werden (z.B. auf ~35 µs laut Datenblatt). Die genannte Klemme liefert insgesamt 6 Byte an Prozessdaten (glaub ich), wären bei 60 Kanälen also 180 Byte, sagen wir mal 200 Byte an Prozessdaten pro Frame. Das dürfte locker unter 40 µs über den Bus gehen.

Würde mal bei Beckhoff nachfragen, was die dazu sagen.
Werde gleich mal ne Beispielkonfiguration in TwinCAT erstellen und mitteilen, wie groß die vorausberechneten Latenzzeiten sind.
... Bis später!


----------



## trinitaucher (19 Februar 2007)

So, eine Beispielkonfiguration mit ca. 200 Byte an Prozessdaten benötigt laut TwinCAT eine vorausberechnete Latenzzeit von unter 25 µs.
Sollte theoretisch also kein Problem darstellen, deine geforderten 50µs zu erreichen.


----------



## MarkusP (21 Februar 2007)

trinitaucher schrieb:


> So, eine Beispielkonfiguration mit ca. 200 Byte an Prozessdaten benötigt laut TwinCAT eine vorausberechnete Latenzzeit von unter 25 µs.
> Sollte theoretisch also kein Problem darstellen, deine geforderten 50µs zu erreichen.


 
Na dann dürfte wohl alles klar sein !!

Hoch Lebe Ethercat !!!

LG


----------



## FG-HH (25 Februar 2007)

Hallo Trintaucher,

hat die Latenzzeitberechnung schon einen aussagefähigen Wert ergeben? Es würde mich sehr interessieren was da so raus gekommen ist.

Danke und Gruß

FG-HH



trinitaucher schrieb:


> @ FG-HH:
> Werde gleich mal ne Beispielkonfiguration in TwinCAT erstellen und mitteilen, wie groß die vorausberechneten Latenzzeiten sind.
> ... Bis später!


----------



## FG-HH (25 Februar 2007)

Oh! die Info hatte ich übersehen.

Danke noch mal.

Gruß FG-HH



MarkusP schrieb:


> Na dann dürfte wohl alles klar sein !!
> 
> Hoch Lebe Ethercat !!!
> 
> LG


----------



## peewit (14 März 2007)

Die Frage ist eigentlich will man ein neues offenes Medium oder bleibt man beim properitären Bussystemen und so weiter wie die letzten 20 Jahre
Das jeder sein Bus erfindet der zu nichts kompatibel ist....

Powerlink:

Nur Hub sind erlaubt,begrenzte Verschachtelungstiefe, Standard Ethernet Geräte (Fremdgeräte) laufen nur über ein Gateway das sicherstellt das das Zeitschlitzverfahren nicht gestört wird. Es sind keine Ethernet-Redundanz und WLAN möglich, ausser man schaltet in des Standard-Mode (nicht Echtzeit) zurück. Aber dann kann man ja gleich MODBUS TCP wieder verwenden. Das Projekt Powerlink mit Switch-Technik hat man fallen gelassen, und freut sich nun über Gigabit HUB-Datenverkehr.
Nur sind Hub leider Geräte von vorgestern !


Ethercat:

ist der INTERBUS auf Ethernet
uralte Idee des INTERBUS gestohlen und auf Ethernet portiert !!
Läuft als Ringsystem, und jeder weiss was bei einen Ringbus für schwächen auftreten können.

Profinet 
Hat ein mehrstufiges Konzept
Profinet CBA: verschalten von Steuerungen über TCP/IP

Profinet SRT:
E/A Austausch im bereich bis 10ms
erst bei hoher Netzlast kommt die Telegrammprioisierung überhaupt
zum tragen, ansonsten können normale Standard-Switches verwendet werden. Profinet Switche sind selbst Profinet teilnehmer und können vom Profinet Controller diagnosiziert werden. Dass heisst ein Ausfall einer Strukturkomponente wird richtig erkannt. Softwarelose Komponentenaustausch durch LLDP-Protokoll, dass auch ein scannen der Netzwerkstruktur ermöglicht.


Profinet IRT: ermöglich isochrone Realtime ca. 1ms (Hardwarelösung)
Protokollprioisierung durch ERTEC200/400 Chip.

Somit sind mehrere Stufe verfügbar die alle eine parallelverwendung von Standard-Komponenten ermöglichen...

Das wichtigste Dabei ist dass man nicht auf die zig-tausende bestehende Bussysteme nicht vergisst (Interbus,Profibus,Canopen,Devicenet etc...)
Diese können mittels Proxy-Konzept jederzeit transparent als Profinet-IO eingebunden werden.

Weiters wird eine stossfreie Redundanz vorhanden sein
Basis ist dar der bekannte Hirschann-Hiperring (Siemens + Hirschmann haben Patent). Welches Redundanzkonzept haben Ethercat + Powerlink ?
So etas ist eine durchgängige Lösung

Weiters haben sich die wichtigsten deutschen Automobilhersteller für Profinet entschieden VW,Audi,Mercedes...


----------



## MarkusP (14 März 2007)

peewit schrieb:


> Profinet IRT: ermöglich isochrone Realtime ca. 1ms (Hardwarelösung)
> ...


 
Damit dürfte die gestellte Aufgabe wohl nicht zu lösen sein, da zu langsam.... Vom Preis gar nicht zu reden.

Übrigens gibt es bei Ethercat sehr wohl ein Redundanzkonzept.
Ebenfalls können die gängigen Bussysteme auch mit eingebunden werden.

Es gibt nicht nur Siemens auf der Welt...

Nicht's für ungut, 

Schönen Abend.


----------



## peewit (14 März 2007)

*EtherNet der bessere Feldbuss ?*

Performance
40 Achsen mit je 20 E/A Bytes
50 E/A Stationen mit insgesamt 560 lokalbus Teilnehmer
2000 Digitale und 200 Analoge I/O 500m Buslänge
Ethercat 276 microsek.
Profinet IRT 768 microsek.
Powerlink v2 2368 microsek.

Bezüglich einbindung andere Bussysteme zielte ich eigentlich auf Powerlink !

Das Ethernet Redundanzkonzept ist leider ein sehr altes Konzept
(grosse Einschränkung)

Diese Redundanz ist eine, die man seit ca 15 Jahren bei Feldbussystemen anwendet, und meiner Meinung nicht wirklich zeitgemäß ist.

Redundanz über den Master 
Vom Master ausgehend gibt es zwei Ethernetabgänge die je nach
unterbrochene Seite im Ring !! über die jeweilige Seite weiter kommunizeren (Habe schon besseres gesehen)

Doch letztendlich bleibt es technisch ein Ring und ermöglicht nicht wirklich
freie Topologien mit beliebiger anzahl an Redunanten Sub-Ringen

Wie sieht es denn aus mit mehreren Controller im selben IO-Netz
Bei Profinet ist das kein Problem, das mehere Controller im selben Netz
direkt auf verschiedene IO-Stationen zugreifen
Es ist kein Single-Master-Slave Konzept
Es ist sogar möglich innerhalb einer IO-Station verschiedenen Controller
die IO's zuzuordnen.

Aber jeder Hersteller hat Vor und Nachteile 

Trotzdem muss man sagen das Ethercat ansich eine tolle Sache ist
EtherCat ist unbestritten der schnellste INTERBUS dem man je realisierte
Mich wundert es trotzdem das Phoenix Contact auf eine Patent-Klage verzichtet hat.

------------------------------------------------------------------
Information:

Powerlink:
Das Echtzeitverhalten vom klassischen Ethernet wird durch das stochastische Zugangsverfahren CSMA/CD eingeschränkt. Mit EtherCAT und Ethernet-Powerlink werden diese Einschränkungen unter Beibehaltung des Ethernet-Konzeptes umgangen. Da Echtzeit-Ethernet für die Automation und Produktion besonders wichtig sind, sind auch hier die Einsatzgebiete von Ethernet-Powerlink (EPL) zu sehen. Ethernet-Powerlink ist ein Layer-2-Protokoll nach IEEE 802.3u, das deterministischen Echtzeit-Datenaustausch über Fast-Ethernet ermöglicht. Es basiert
auf einer Hub-Struktur und nutztdas Ethernet-Frame und auch die Komponenten von Fast-Ethernet. Wie andere Feldbusse auch kann Ethernet-Powerlink von der Sensor-Aktor-Ebene, der so
genannten Feldebene, bis hin zur Leitebene eingesetzt werden. Die einzelnen Komponenten sind über IP-Adressen über alle Ebenen hinweg, unternehmensweit und über das Internet ansprechbar.
Ethernet-Powerlink arbeitet im Master-Slave-Betrieb mit einem isochronen
Zeitschlitzverfahren und unterstützt den Datentransport mittels IP-, UDP- und TCPProtokoll. Dieses einfache Zugangsverfahren, das Slot Communication Network Management (SCNM), bildet die Grundlage für den Determinismus. Dabei verteilt die Managing Node (MN), die die Funktion des Managers innehat, die Zugangsberechtigung der Teilnehmer auf das Medium. Sie verhindert Kollisionen und gibt den Zeittakt für die Synchronisation aller Teilnehmer vor. Die Geräte, die im EPLKonzept
als Controlled Node (CN) bezeichnet werden, senden nur dann, wenn sie
vom Manager dazu aufgefordert werden. Das EPL-Protokoll ist ein deterministisches Zugangsverfahren, das in einem
abgegrenzten Netzwerk-Segment, der Realtime-Domain, abläuft. Der zeitkristische Datenverkehr erfolgt im sogenannten Protected Mode. In dieser Betriebsart können Zykluszeiten von 1 ms bei über 30 Stationen und 46 Byte Nutzdaten realisiert werden. Der weniger zeitkrische Datenverkehr wird nicht in dieser Netzwerk-Domäne abgewickelt und belastet dadurch auch nicht das Realtime-Segment. An die Realtime-Domäne können bis zu 240 Stationen angeschlossen werden. Die Frame-Länge der EPL-Telegramme kann bis zu 1.500 Byte betragen, die Zykluszeiten liegen bei Telegrammen in Standardlänge bei etwa 100 Mikrosekunden.
Von der Topologie her sind für EPL alle Varianten denkbar, außerdem kann ein solches Netzwerk mit Hubs und Routern erweitert und an andere IP-Netze angebunden werden. In der Anwendungsschicht setzt Ethernet-Powerlink auf CANopen. Die Aktivitäten von Ethernet-Powerlink werden von der Ethernet Powerlink Standardization Group (EPSG) vorangetrieben.
Das EPL-Protokoll ist ein deterministisches Zugangsverfahren für Ethernet-
Powerlink (EPL). Da Ethernet-Powerlink in Automatisierungs-,
Produktions- und Fertigungsumgebungen eingesetzt wird, fallen
zeitkritische Daten an, die mit definerter Vorhersagbarkeit
übertragen werden müssen. Zu diesem Zweck arbeitet Ethernet-
EPL-Protokoll EPL protocol Struktur des Ethernet-Powerlink
Zykluszeit von Ethernet- Powerlink in Abhängigkeit
von der Stationszahl Powerlink mit einen abgegrenzten Realtime-Domäne, einem speziellen Netzwerk-Segment über das der der zeitkrische Datenverkehr abgewickelt wird. An ein solches Realtime-Segment können bis zu 240 Controlled Node (CN), das ist die Bezeichnung
für die Stationen, angeschlossen werden. Das EPL-Protokoll ist ein zyklisches Zugangsverfahren, das sicherstellt, dass alle
Controlled Nodes mit einer zeitlichen Verzögerung von unter einer Mikrosekunde zueinander synchronisiert sind.
Beim EPL-Protokoll sendet die Managing Node einen Startzyklus (SoC) als Broadcast über die Realtime-Domäne und überprüft damit das Zeitverhalten. Dieser Startzyklus kennzeichnet den Beginn der streng deterministischen Zyklusperiode, bei dem der Managing Node im Unicast an alle Controlled Nodes einen Sendeaufruf sendet, die dann mit einer entsprechenden Response-Nachricht ihre Sendebereitschaft
dokumentieren. Da das Poll-Response im Multicast gesendet wird, empfangen es alle Controlled Nodes und können ihren Sendewunsch zurückstellen. Die Übertragung der zeitkritischen Daten erfolgt isochron in Zeitfenstern. Jeder Station wird dabei ein Zeitfenster zugeordnet. Während dieser Periode können die Knoten IPTelegramme,
das sind die aus der Datenkommunikation bekannten Datagramme, in
dem der Station zugeordneten Zeitfenster senden. Einzelne Zeitfenster können im Multiplex mehreren Stationen zugeordnet werden.
Der isochronen Übertragung folgt ein Zeitfenster für asynchrone Daten. Dies sind zeitunkritische Diagnose- und Messdaten. In einem Übertragungszyklus wird jeweils nur ein Zeitfenster für asynchrone Daten einer einzelnen Station zugeordnet. Die Zuordnung der Zeitfenster übernimmt die Managing Node, die die Anfragen der einzelnen Stationen nach Prioritäten gliedert. Für sicherheitskritische Anwendungen gibt es die Protokollversion EPLsafety. Die Safety-Lösung wurde aber von KW-Software entwickelt 

Ethercat
Die Verkürzung der Durchlaufzeiten wird beim EtherCAT-Protokoll dadurch erreicht,dass die Telegramme, das sind die aus der Datenkommunikation bekannten Datagramme, nach dem Empfang nicht mehr interpretiert und kopiert werden, sondern “On-the-Fly” verarbeitet werden; also quasi im Vorbeifliegen. Dabei werden die UDP-Telegramme, die an eine so genannte Fieldbus Memory Management Unit (FMMU) adressiert sind, von dieser gelesen, während das Telegramm zur nächsten Station oder Steuergerät weitergeleitet wird. Auf ähnliche Weise werden Eingangsdaten eingefügt während das Telegramm die Station passiert. Dadurch liegen die Verzögerungszeiten der Datentelegramme bei wenigen Nanosekunden (ns).
EtherCAT arbeitet im Master-Slave-Betrieb; masterseitig kommen in der EtherCATTopologie kommerziell verfügbare Netzwerkkarten (NIC) oder On-Board-Controller zum Einsatz. Durch die FMMUs in den Slave-Knoten und den direkten Speicherzugriff (DMA) über die Netzwerkkarten, ist der komplette Prozess hardware-orientiert und unabhängig von Laufzeiten durch Protokollstacks, von CPU-Performance oder Software-Implementierungen. So beträgt die Aktualisierungszeit von 1.000 verteilten I/Os nur 30 Mikrosekunden. Innerhalb eines Ethernet-Telegramms können bis zu 1.486 Byte an Prozessdaten übertragen werden und das in einer Datentransferzeit von 300 Mikrosekunden. Voraussetzung für diese kurzen Transferraten ist eine exakte Synchronisation der verteilten Prozesse. Diese wird durch die genaue Ausrichtung des verteilten
Taktsignals erreicht, wie es im Standard IEEE 1588 beschrieben ist.
Von der Funktion her ist EtherCAT vergleichbar einem einzelnen großen Ethernet-Teilnehmer, der Ethernet-Datagramme, in Feldbussen auch als Telegramme bezeichnet, sendet und empfängt. Ein solcher Ethernet-Teilnehmer besteht aus vielen EtherCAT-Slaves, die die Telegramme während des Durchflusses bearbeiten indem sie für den jeweiligen Slave bestimmte Nutzdaten aus dem EtherCAT-Frame herausnehmen oder einfügen und gleichzeitig das Datagramm an die folgende Station
weiterleiten. Die Slaves können untereinander direkt, im Multicast und im Broadcast kommunizieren. Das EtherCAT-Protokoll verwendet Ethernet-Telegramme, das sind die aus Ethernet bekannten Ethernet-Frames, und hängt an dieses einen zwei Byte langen EtherCATHeader. Ein EtherCAT-Telegramm kann mehrere EtherCAT-Kommandos für verschiedene Slaves und deren direkt adressierbare Speicherbereiche enthalten. Die
Größe des Direct Memory Access (DMA) beträgt 64 KB. Der EtherCAT-Datenrahmen besteht aus dem Ethernet-Frame, gefolgt von einem 2
Byte großen EtherCAT-Frame, dem Nutzdatenbereiche mit den EtherCAT-Kommandos folgen. Abgeschlossen wird der EtherCAT-Datenrahmen durch ein 4 Byte langes Datenfeld für die zyklische Blockprüfung (CRC).
Erfolgt die Kommunikation über das UDP-Protokoll und IP-Protokoll, dann folgt dem Ethernet-Header zuerst der IP-Header, dann der UDP-Header und danach der EtherCAT-Header. EtherCAT, ein Feldbus-Konzept für die Automation und Produktion, kann in verschiedenen Topologien realisiert werden. Prinzipiell sind alle Ethernet-Topologien möglich, einschließlich der Sterntopologie des Ethernet-Switching. Ebenso kann EtherCAT auch in Bus- und Linientopologien, wie sie von anderen Feldbussen her
bekannt ist, aufgebaut werden. Als Übertragungsmedien stehen die bekannten Ethernet-Übertragungsmedien wie TP-Kabel, Lichtwellenleiter und Plastikfasern zur Verfügung.


----------



## MarkusP (15 März 2007)

Danke für die professionelle Information !

So wie sich das darstellt, hat nun eben jedes System seine Vor- und Nachteile. Wichtig glaube ich ist, das für den jeweiligen Fall richtige System einzusetzen, und hi und da über den Tellerrand zu schauen!

Schade eigentlich ist, daß sich jetzt wieder so viele eigene Ethernet Bussysteme entwickeln, ähnlich wie es bei den "alten" Feldbussen" der Fall war. Und dies war eigentlich nicht das Ziel für die neue IEC-Norm! Ausser beim Physical Layer ist da gar nichts kompatibel.

Also beten wir wieder das brav nach, was uns andere vorbeten, ist halt wie bei der Religion.

Schönen Tag noch !!


----------



## zotos (15 März 2007)

Die infos sind sehr interessant. Das EtherCAT auf Interbus Technik basiert war mir neu.


----------



## trinitaucher (15 März 2007)

@ peewit:
Für mich klingt es so, als würdest du ne Hetze gegen EtherCAT starten.
Die Problemstellung im Thread lautete so: 



			
				FG-HH schrieb:
			
		

> Wir wollen die Steuerung inkl. Bussystem für eine "normal Maschinensteuerung" einsetzen. Kritischster Punkt in der Anwendung ist, an bis zu 60 Analogdatenpunkten (16Bit Messwerte) in einem 0,05 msek. Raster aufzuzeichnen und auszuwerten (0,05 msek Raster stimmt!).
> Frage ist:
> - Welches Bussystem (EPL, Profinet, EtherCat) ist dafür besser oder überhaupt geeignet?
> - Lässt sich die daraus resultierende Datenflut auf einer zentralen CPU bewältigen?



Diese Aufgabe kann EtherCAT prinzipiell bewältigen.



peewit schrieb:


> Trotzdem muss man sagen das Ethercat ansich eine tolle Sache ist
> EtherCat ist unbestritten der schnellste INTERBUS dem man je realisierte
> Mich wundert es trotzdem das Phoenix Contact auf eine Patent-Klage verzichtet hat.



Das verschiedene Kommunikationsprinizipien der Bus-Systeme sich ähneln, kommt nunmal vor. Das Zeitscheibenverfahren ist ja auch nicht neu.
Deine letztere Aussage zeigt, dass du das EtherCAT-Prinzip noch nicht verstanden hast. Phoenix kann nicht klagen, weil EtherCAT nichts mit Interbus zu tun hat. In einigen Publikationen wird zwar davon gesprochen, dass es dem Interbus ähnelt, aber mehr auch nicht. Im Gegensatz zu Interbus werden die Daten nicht durch den Bus bis zum Master zurück "geschoben", sondern von Teilnehmer zu Teilnehmer "weitergeleitet" und von diesen ausgewertet, incl. Adressierung, die es beim Interbus so nicht gibt. Der letzte ETC-Slave erkennt, dass nichts mehr folgt und sendet das Telegramm zum Master zurück. Deswegen ist EtherCAT auch hot-Pluggin-fähig, Interbus meines Wissens nach nicht.



peewit schrieb:


> (...)
> Diese Redundanz ist eine, die man seit ca 15 Jahren bei Feldbussystemen anwendet, und meiner Meinung nicht wirklich zeitgemäß ist.
> 
> Redundanz über den Master
> ...


Was sind denn deine zeitgemäßen Vorstellungen von Redundanz ?

Und nun nochmal zu deiner Aussage, dass jedes Bussystem seine Vor- und Nachteile hat:
Wenn du dir mal den Kundenstamm von Beckhoff ansiehst, wirste bemerken, dass es zu bestimmt 90% der Maschinenbau ist. In einer Maschine kommen im Gegensatz zur Prozessindustrie und Leittechnik eher selten verteilte Controller zum Einsatz in der Form, dass sie im Sub-Millisekundenbereich miteinander kommunizieren müssten. EtherCAT ist von Design her optimal auf die schnelle I/O- und Antriebstechnik ausgelegt. Als Redundanzkonzept in einer "normalen" Maschine kann eine Ring-Struktur zudem durchaus sinnvoll sein.

EtherCAT kannste auch nicht mit dem ProfiNet-Konzept vergleichen. Das ist für die Prozessindustrie ausgelegt und eben nicht für schnelle Maschinensteuerungen.
Generell finde ich hinkt der reine Vergleich der Datenblätter.

Hör doch bitte auf, gegen EterhCAT zu pöbeln. So kommt es nämlich rüber.


----------



## peewit (15 März 2007)

Da ist diesem Forum hauptsächlich EtherCat-Fans sind möchte ich doch auch ein wenig Details rund um das System reinbringen. Und dmit nicht n schwärmen sondern Stärken und Schwächen gegenüber stellen.
Viele in diesem Forum suchen mitunter ein zukünftiges System, und dabei ist es wichtig das man möglichst viele Details kennt.

Alle Systeme haben ihr Anwendungsgebiet !!

Meiner Meinung nach ist speziell für schnelle Applikation (Maschinenbau, Antriebssteuerung EtherCat immer noch das beste System.

Trotzdem möchte ich weiterhin Details über EtherCat hier bringen
denn die meisten Intressieren sich auch hier in diesem Forum dafür



EtherCAT wird von der Fa. Beckhoff entwickelt. Sämtliche Rechte an diesem System liegen bei Beckhoff. Es wurde eine Nutzergruppe gegründet, in der man kostenlos, jedoch gegen zur Verfügungstellung seines Firmenlogos, Mitglied werden kann. Diese Nutzergruppe und somit seine Mitglieder besitzt,
jedoch keinerlei legale Rechte am System.

Hauptaussage:
- vollständig Ethernet kompatibel
- Kommunikation vollständig in Hardware; maximale Performance
- Hocheffizientes Protokoll
- Nutzung von Standard−Ethernet−Karten
- Beliebige Topologie
- Mischung von Echtzeitdaten mit Standard TCP/IP möglich
- Ethernet als Backplane

Das System besitzt seine Stärke als Rückwandbussystem für Klemmen. Es
wird in zwei physikalischen Varianten angeboten: E−Bus und Ethernet. E−Bus basiert auf Differenzspannungssignalen (LVDS), ist nur für kurze Strecken geeignet (<10m), z.B. innerhalb einer Klemme, und garantiert keine galvanische Trennung. Grund für die Verwendung dieses Physik ist, dass sie laufzeitmäßig günstiger als Ethernet−Physik ist. Um echtes Ethernet−Nutzen zu können (Standard−Stecker, Kopplung an andere Ethernet−Geräte etc.) ist jedoch die Verwendung der Ethernet−Physik nötig. Ein Vergleich ist daher nur bei Betrachtung der gleichen Physik sinnvoll. Die Daten werden dem Ethernet−Telegramm im Durchlauf entnommen und/oder eingefügt ("Interbus−Prinzip"). Die Topologie eines EtherCAT−Systems ist prinzipiell frei. Standardmäßig geht man von einer Linienstruktur aus. Tatsächlich verbirgt sich implizit dahinter
immer ein Ring. Abzweige sind über I/O−Koppler möglich. Ein Stern
lässt sich nur realisieren, wenn die PLC bereits genügend Ethernet−Anschlüsse (sprich: Netzwerkkarten in einem PC) besitzt. Die Verwendung von Standard−Switches zum Aufbau eines Sterns ist nicht möglich. Baumstrukturen sind unter Verwendung von I/O−Klemmen mit Stichleitung möglich, jedoch lassen sich so nicht beliebige Baumstrukturen realisieren. Switches sind nur zwischen Master und dem ersten EtherCAT−Knoten erlaubt. Standard−Ethernet−Komponenten können entweder an genau diesem Switch angekoppelt werden, oder aber an speziellen Switchingport−Klemmen. Die Kommunikation zwischen den Standardkomponenten und EtherCAT−Geräten erfolgt niemals direkt, sondern stets über den sog. Virtual Switch in der
PLC, also einen Umweg, der Laufzeit kostet und einen Flaschenhals darstellt. Zur Netzwerkanalyse werden spezielle Analysegeräte benötigt, da der Datenstrom abhängig vom Messpunkt ist.​


----------



## MarkusP (15 März 2007)

peewit schrieb:


> E−Bus basiert auf Differenzspannungssignalen (LVDS), ist nur für kurze Strecken geeignet (<10m),
> 
> Die Verwendung von Standard−Switches zum Aufbau eines Sterns ist nicht möglich.


 
Meld' mich auch mal wieder kurz zu Wort.

Kurze Strecken von <10 m ist relativ, da man auf 10m therotisch 833 Klemmen stecken könnte, und das bis zu 6666 E/A's sein könnten.
(ist natürlich nicht so, will nur ein Gefühl für "kurze Strecken" vermitteln)

Aber da man sowieso mehrere Knoten einsetzen wird, und dort die Physik wieder Ethernet ist, ist man wieder bei den standardmäßigen 100m zwischen zwei Kopplern.

Und für den Preis eines Ethercat-Kopplers haben wir früher nicht einmal das Steckermaterial für unser Feldbussystem bekommen. (gg)

EtherCat über Switch ist übrigens in Entwicklung und für heuer angekündigt.

Weiters kann EtherCAT mit Interbus-S nicht wirklich verglichen werden, geklagt werden wird schon sicher alleine deswegen nicht, da die Urentwicklung von Interbus-S auch nicht von Phönix selbst sein soll !? (habe ich mal gehört)

Schönen Abend

Markus.

PS:
Seid's nicht immer alle gleich so garstig miteinander, wir wollen alle Meinungen hier hören, um sich ein Bild machen zu können !
Aber ich bewundere die Leidenschaft, der doch sonst so "trockenen" Techniker !

Hoch lebe E........t !


----------



## peewit (15 März 2007)

Bitte nehmt nicht alles gleich Persönlich !!

Das was ich geschrieben habe sind trotzdem momentane Tatsachen

Es freut mich aber das sich immer wieder jemand Zeit nimmt und diese Diskussion am Leben hält.



Zum Thema:

Wer hat INTERBUS erfunden !!

Es war einmal eine gute Idee.....

Zuerst kam INTERBUS-C (Intel Bitbus)

Dann hat Phoenix mit Siemens gemeinsam den INTERBUS-P (Profibus) entwickelt
So mancher wird sich über die Namensgebung wundern , aber das war wirklich so !! Wer es nicht glaubt der kann ja im Internet auch danach suchen was 'interbus-p' war.

Dabei hat man sich aber zerstritten und jeder hat seine eigenen IDEE weiter verfolgt.  Siemens hat mit dem Profibus in den ersten Jahren grosse Probleme gehabt sich durchzusetzen, da die ersten ansätze ziemlich unbrauchbar waren.

Und bei Phoenix gab es einen Studenten der bei seiner Studienarbeit ein sehr interessanten Bus-Konzept sich ausdachte.

Diese Idee (hat man ihm abgekauft) und daraus denn Urform des INTERBUS-S entwickelt (Somit ist die Idee innerhalb von Phoenix aufgetaucht und auch realisiert worden)

wobei es bis dahin auch einige zwischenschritte gab.
Bei Phoenix Intern wird dies in Generationen angegeben.
Es gibt somit G1-G4 (die nicht alle zueinander direkt kompatibel sind)
Erst ab Generation 3 war der Interbus als 5 Draht Bus ausgeführt (2xSende+2xEmpfangsleitung+Masse) , vorher war mittels 15 Poligen Stecker realisiert mit extra Hardware-Handshake Leitungen​Interbus ist ansich eine total geniale Idee mit maximaler Performance
Echtzeitfähig, alle eingelesene Eingänge stammen automatisch vom gleichen Zyklus, und alle Ausgänge werden absolut synchron ausgeben.
Dadurch das jeder Buskopf automatisch eine Repeater ist, ergeben sich viele galvanisch getrennte Teilbusstrecken die hervorragend Diagnosiziert werden können.
Hat aber seine 'Probleme bei Ringunterbrechnungen, das dadurch so mancher Kunden sich vom IBS getrennt hat.......

Tja nichts ist perfekt.....

Ich hoffe du bist froh das ich diesmal nichts über EtherCat geschrieben habe.


----------



## MarkusP (16 März 2007)

*Interbus-S vs. EtherCAT*

Guten Morgen,

kann das eigentlich nur bestätigen, haben in den letzten 10 Jahren weit über 1000 Interbus-S Slaves verbaut!

Um das Problem mit dem Ausfall in Grenzen zu halten, platzieren wir halt mehrere Interbus-S Master, und machen zusätzlich einige Fernbus-Stichs. Ist praktisch aber bei unseren Anwendungen nicht das Problem. Ein Meilenstein in der Entwicklung war für uns, dass nun der restliche Bus auch bei einem Ausfall weiterläuft.

Das Hauptproblem ist halt, daß dieser Bus quasi tot ist, ich meine damit, es praktisch Null Weiterentwicklung gibt (speziell von Nicht Phönix-Anbietern), und sich Phönix jetzt total auf Profinet konzentriert.  

Das hilft mir aber wenig...

Von EtherCAT erwarte ich mir nun ein weiterführen der "bisherigen" Lösungen, zum konkurrenzfähigen Preis. Und da wir einige hundert Slaves benötigen, die am selben Glasring angeschlossen sind, bleibt derzeit nicht mehr viel Auswahl !

Schönen Tag noch (das Wetter passt ja)

MP


----------



## mike_nl (22 März 2007)

*Re:*

Hallo Maxl,

Zitat von Maxl:
Also bei EPL in Kombination mit X20 ist meines Wissens nach bei 200µs Schluss.


Stimmt nicht ganz. Man kann im Servocontroller verschiedene Funcktionen mit 100us ablaufen lassen. Die Datenflut sollte nicht das Problem sein. Ich habe selbst sehr grosse Systeme zur DVD Herstellung in Betrieb genommen. 145 Achsen mit EPL. dazu unmengen an I/Os. Die Frage ist eigentlich wie wird das ganze programmiert und von wem? Hat der Ing. Erfahrung?

Gruss,

Mike


----------



## muffensauser (27 März 2007)

*Andere Systeme*

Hallo!
Ich bin auf diesen Thread gestoßen und denke/hoffe, dass mir vielleicht jemand von euch helfen kann. (Wollte nicht extra nen neuen Thread aufmachen)
Ich studiere Wirtschaftsingenieurwesen und sol nun eine Studienarbeit schreiben. Dabei soll ich die verschiedenen Ethernetsysteme Powerlink, Ethernet/IP, Profinet, Safetynet p, EtherCAT und Sercos III miteinander vergleichen. 
Zu EtherCAT,EPL und Profinet findet man ja doch einiges, aber bei den anderen ist eher Ebbe angesagt. Ich hab schon einiges zu den Sachen gelesen(Homepages der Organisationen/Herrsteller, www.aud24.de,etc.)
Das Problem ist nur, dass die Grundaussage von allen Systemen: "Wir können alles" gleich ist :-( 
Die meisten technischen Unterschiede (Geschwindigkeit, Topologie, ASIC ja/nein) hab ich denke ich schon gefunden.
Aber ich soll nicht nur eine Checkliste der Kennwerte erstellen. Meinem Prof ist es auch wichtig, dass Punkte wie Implementierungsaufwand, Kosten für Implementierung und Geräte sowie die vom Herrsteller angepeilten Einsatzbereiche angesprochen werden. 
Da ihr anscheinend schon Erfahrung mit dem Thema habt, wollte ich euch mal fragen, ob ihr mir vielleicht noch ein paar Tipps zur Informationssuche und/oder Erfahrungsberichte liefern könnt?

Gruß Christoph


----------



## mike_nl (27 März 2007)

*Re:*

Hallo Christoph,

zu EPL, Ethernet Powerlink, schau mal hier:
www.ethernet-powerlink.org und hier www.automotion.info.

Die beiden Links sollten Dir weiterhelfen koennen. Sollten
noch Fragen besetehn wende Dich an www.br-automation.com.

Zu Sache der Erfahrung: schau hier wer Mitglied ist in der EPL Gruppe.
http://www.ethernet-powerlink.org/index.php?id=27. Alle grossen sind dabei.
Selbst Firmen die nicht mit auf die Leiste wollten wegen, naja man gibt sich
ja schliesslich keine Bloesse. Ich kenne die komplette Liste und es ist ein lacher.
Wissen ist fuer jeden, und nicht nur fuer DEN grossen. Oder Du nimmst pers.
Kontakt mit mir auf.

Gruss,

Mike


----------



## trinitaucher (27 März 2007)

mike_nl schrieb:


> Alle grossen sind dabei


Das kann man glaub ich auch für die anderen Systeme sagen. Die entsprechenden Nutzerorganisationen findest du auch für diese. Bei EtherCAT auf www.ethercat.org, bei Profinet http://www.profibus.com/rpa/germany/, bei Sercos III http://www.sercos.de/, bei Ethernet/IP http://www.ethernetip.de/.
Meist sind die "großen" überall mit drin, auch wenn sie manchmal überhaupt (noch) keine Produkte anbieten.

Zu den Implementierungskosten sollteste mal auf den Seiten der Nutzerorganisationen suchen, welche Firmen in mehreren Listen auftauchen und somit auch evtl Produkte für mehrere Systeme anbieten. Dann könnteste bei denen Anrufen und nach den Kosten fragen. Wenn's z.B. ein Antriebsregler ist, fragste einfach, wieviel dieser einmal mit EtherCAT-, mit Powerlink- mit Sercos III-Interface usw. kostet.
Zudem siehts anhand der Produktpaletten auch, welches System wofür bevorzugt im Einsatz ist.

Den Implementierungsaufwand kannste eigentlich nur dann sinnvoll vergleichen, wenn du stets den gleichen Beispiel-Anwendungsfall zugrunde legst. Aber nicht für jedes System gibt's die gleichen Komponenten.
Beispiel: Powerlink, EtherCAT und Profinet-I/O für modulare I/O-Systeme für SPS von B&R, Beckhoff und Phoenix-Contact. Es sind immer Master-Anschaltungen und Buskoppler nötig, dazu noch die benötigten I/O-Module.... dann mal los


----------



## zotos (27 März 2007)

trinitaucher schrieb:


> Das kann man glaub ich auch für die anderen Systeme sagen. Die entsprechenden Nutzerorganisationen findest du auch für diese. Bei EtherCAT auf www.ethercat.org, bei Profinet http://www.profibus.com/rpa/germany/, bei Sercos III http://www.sercos.de/, bei Ethernet/IP http://www.ethernetip.de/.
> Meist sind die "großen" überall mit drin, auch wenn sie manchmal überhaupt (noch) keine Produkte anbieten.
> ...



Ja das ist mir auch schon aufgefallen.

Woran das liegt? Ich gehe mal davon aus das selbst die "großen" sich noch nicht sicher sind wo sich der Markt hin bewegt.


----------



## Cliff (27 März 2007)

> Ich gehe mal davon aus das selbst die "großen" sich noch nicht sicher sind wo sich der Markt hin bewegt.



War letztens auf einem Seminar bei Phoenix wg. ProfiNet. Dort wurde das so dargestellt, als wenn sich beim PN Siemens und Phoenix ein wenig mehr als üblich zusammengeschmissen haben. Weiterhin wurde die 'Behauptung' in den Raum geschmissen das in den grossen Automobilwerken der PN  der  'Bus der Busse ' ist (Zumindest für Neuanlagen)...

...aber genaues weiss man wohl erst in 100 Jahren ;-) 

Mir ist es letzendlich wurscht. Im Grunde genommen gibt ja der CPU- Hersteller die einsetzbaren Bussysteme durch das mehr oder weniger an Betriebssystem- seitiger Unterstützung vor... 

Gruss Cliff


----------



## mike_nl (28 März 2007)

Hallo Cliff,

'Buss der Busse und die Automobilkonzerne'

Aus eigener Erfahrung wird da sehr oft und viel in den Raum geschmissen, von allen Herstellern. Das gleiche gilt fuer die Luft und Raumfahrtindustrie. Fue die haben sehr viele Kollegen von mir vor einiger Zeit sehr grosse realtime Diagnostiksysteme via PowerLink erstellt, um endlich schwaechen im System offenlegen zu koennen. Man denke dabei an den grossen Airbus. 
Und man hat gefunden wonach man suchte. Obwohl es Franzosen waren ;-). Das ist aber eine persoenliche Einstellung gegenueber dem Land, das wollte ich nur erwaehnen.

Ich selbst habe vor Jahren bei der Nasa Systeme progarmmiert und in Betrieb genommen die nun mittlerweile ebenfalls mit EPL arbeiten. Realtime Diagnostik im Highendbereich. Gut dabei kommen sehr schnelle APCs und auch dementsprechende IOs zum Einsatz. 

Ich bin zwar verfechter einer bestimmten Marke, aufgrund von Erfahrung, aber jeder ist seiner Automatisierung Schmied, oder wie heisst das Deutsche Sprichwort. Oder war das eine Fabel ;-)...

Gruss, 

Mike


----------



## Cliff (28 März 2007)

Hi Mike,

im Grunde genommen stimme ich Dir ja zu. Deswegen auch das mit den '100 Jahren'. Welcher Techniktrend schon genau vorherzusagen?

Aber wie schon gesagt, letzendlich bestimmt meiner Meinung nach die eingesetzte CPU und deren Unterstützung eines bestimmten Systemes den eingesetzten Bus. Warum soll ich mir z.B. in der Siemens- Welt (Die wird mir (leider?) von unseren Kunden aufgezwungen) die Mühe machen und z.B. irgendwelche Hersteller- fremden CP's einsetzen nur um z.B. den Interbus hier einzusetzen? Spätestens wenn es dann um die Einbindung dieser CP's in's System inklusiver der ganzen dazu gehörigen Systemdiagnose geht, heisst es dann meistens 'Mach's Dir selbst...'

Gruss Cliff


----------



## Unregistrierter gast (28 März 2007)

mike_nl schrieb:


> Ich selbst habe vor Jahren bei der Nasa Systeme progarmmiert und in Betrieb genommen die nun mittlerweile ebenfalls mit EPL arbeiten. Realtime Diagnostik im Highendbereich. Gut dabei kommen sehr schnelle APCs und auch dementsprechende IOs zum Einsatz.
> 
> Mike



Mann, dann bist du ja jetzt als SPSler völlig unterfordert !


----------



## muffensauser (28 März 2007)

*Danke erstmal*

Hallo Leute,
danke erstmal für die Antworten. Ich habe schon mit einigen Herstellern/Dienstleistern telefoniert um herauszufinden, weshalb sie gerade dieses oder jenes System unterstützen. Aber dann bekommt man immer so tolle Aussagen wie die Offenheit und Performance des Systems.

Ich wollte nur mal in aller Kürze darstellen, wie ich die Sache momentan sehe:

EPL:
Ist ein relativ einfach gestricktes System, welches sich vor allem für "normale" Automatisierungsaufgaben eignet. Das Master/Slave-Prinzip in Verbindung mit Hubs erzeugt nach meiner Meinung einen ziemlich hohen Traffic und geht bei steigender Teilnehmerzahl sehr schnell zu Lasten der Zykluszeit. Deswegen schätze ich es für Motioncontrolanwendungen mit vielen Teilnehmern als eher ungeeignet ein.

Ethernet/IP:
Ist wohl das einfachste System von allen. Aber es handelt sich meiner Meinung nach eher um weiche echtzeit, da ich denke, dass die harten Anforderungen bei Verwendung von UDP nicht erfüllt werden können.
Dafür scheint es günstig zu sein.

EtherCAT:
Das schnellste? Die Idee mit der On-the-fly Verarbeitung scheint mir echt clever zu sein. Ist meines Erachtens auf den Bereich Antriebssteuerung ausgelegt und bietet daher für normale Anwendungen zu viel Performance die mitgezahlt werden muss. (Was heißt das eigentlich, dass bei EtherCAT Ethernet auch als Rückwandbus genutzt wird?)

Safetynet:
Gibts in zwei Varianten. Die eine scheint auf ähnliche Werte wie EtherCAT zu kommen. Die andere spielt eher in der Liga von EPL und Ethernet/IP.
Ist also quasi ein Allrounder und für alle Belange geeignet. Dafür wird es wohl noch einige Zeit dauern, bis es verfügbar ist, was natürlich den Markteinstieg erschweren wird.

Profinet:
Gibts auch in zwei Varianten IRT--> EtherCAT/RT-->Powerlink (NRT vernachlässige ich jetzt mal)
Nachteile von IRT scheinen die Verwendung dieses ERTEC-Chips zu sein, welcher wohl ziemlich teuer ist. Außerdem kann man wohl nur teure von Siemens zertifizierte Switches oder gemanagete Switches (QoS) verwenden.

Sercos III:
Ist auch Antriebsorientiert. Mir gefällt die Möglichkeit beide Ethernetports am Master zu nutzen um anstelle eines Rings auch zwei unabhängige Linienstrukturen aufbauen zu können. Dürfte doch einiges für die Performance tun, oder?

So, das sind meine bis dato gewonnenen Eindrücke. Um Verbesserungen wird gebeten 

Danke soweit.

Gruß Christoph


----------



## JesperMP (28 März 2007)

Hallo muffensauser.

Ist hier ein Vergleich von 14 Ethernet basierte Protokollvarianten:
http://www.ethernet.industrial-networking.com/articles/articledisplay.asp?id=854

Es ist ein Artikel mehr als eine tiefe Erklärung.
Aber es ist das beste, das ich im Augenblick finden kann.

Warnung: Der Autor ist von Siemens.


----------



## JesperMP (28 März 2007)

Doch hier ist noch ein Artikel:
http://www.ethernet.industrial-networking.com/articles/articledisplay.asp?id=1165

Warnung: Die Autoren sind von Rockwell.

Es ist bemerkenswert, wie die zwei Artikel im Vergleich der Motion Fähigkeiten von Profinet und von Ethernet/IP sich unterscheiden.
Die harte Sache ist, wohin man gute, zuverlässige und unabhängige Informationen erhält.


----------



## MarkusP (28 März 2007)

muffensauser schrieb:


> Was heißt das eigentlich, dass bei EtherCAT Ethernet auch als Rückwandbus genutzt wird?)


 
Das heisst, das Ethercat auch durch die Klemme "fährt". Bei den meisten anderen Systemen wird immer (meistens) der "firmeneigene" Bus als Rückwandbus verwendet, und die Buskoppler sind eigentlich immer so eine Art Gateway. Das wäre aber bei ETHERCAT nicht möglich, da die herkömmlichen Systeme dann auf E/A Ebene viel zu langsam wären.
Interessant dabei ist, dass Beckhoff eigentlich preislich im Nachteil sein müsste, da ja jede Klemme einen ASIC (oder wie das bei denen heißt) braucht, und nicht nur einen, wie bei der Buskoppler Variante. Dem ist aber ganz und gar nicht so... (siehe Preise Profinet IRT)

Die Frage ist, ob man ETHERCAT wirklich braucht. Da es sich aber entgegen Deiner Vermutung im Preis nicht wirklich niederschlägt - warum nicht ? (was bringen z.B. die kolportierten 180-190 PS der neuen Suzuki ?, aber Spaß beiseite) Für mich gilt der alte Werbespruch "Gut ist wenn man's hat wenn man's braucht".

Andererseits hat jedes System seine Vor- und Nachteile und seine Berechtigung. Das natürlich von jedem Hersteller SEIN System gepriesen und gepusht wird, versteht sich von selbst. Und SIEMENS als Grossmacht ist nicht zu unterschätzen.

Profibus-DB hinkte z.B. lange Zeit hinter HINTER Interbus-S her, bis dann aus strategischen Gründen der Profibus von SIEMENS voll gepusht wurde. Und heute ist das so ziemlich "Standard", weil halt u.a. weit verbreitet und von fast jeder Firma implementriert.

Ich persönlich glaube, dass die meisten Anwender, so wie wir, mit vielen Bus-Systemen sehr gut leben können (wir setzen z.B. 5 veschiedene Systeme an einer einzigen Anlage ein) und nur im Einzelfall muss man wirklich aus Gründen der Performance oder Funktionalität ein spezielles System auswählen und einsetzen. (ich spreche da nur für mich)

Aber im Normalfall wird, wie schon weiter oben erwähnt, das Bussystem vom MASTER sprich SPS bestimmt. Nun such doch mal nach ETHERCAT Komponenten für SIEMENS ! Und genau das meine ich.

Die Hersteller für z.B. E/A-Geräte, Servos, Umrichter etc. versuchen natürlich möglichst für alle Bussysteme offen zu sein, um ihre Hardware zu platzieren. (eh klar) Und da wird dann aus strategischen Gründen der eine oder andere Bus mehr oder weniger forciert.

PS:
Wir haben derzeit eine Anwendung, wo wir uns wirklich nach langem Suchen dann für ETHERCAT entschieden haben, da dieses System für die Bedürfnisse optimal ist, wie kein anderes, und auch der Preis passt.
Und Siemens ist für uns (Gott sei Dank) kein absoluter Muss durch den Kunden ! Diese Anlage wäre aber mit PROFINET so nicht realisierbar bzw. finanzierbar gewesen.

So, nun beende ich meinen nicht sehr technischen "Senf zur Sache", pure Technik gabs's ja weiter oben, sind übrigens sehr informative Link's.

In diesem Sinn,

sucht alle weiter nach dem heiligen Gral  ,

LG

Markus.


----------



## peewit (28 März 2007)

*Siemens + Phoenix Contact = ProfiNet*

Siemens + Phoenix Contact = ProfiNet

Was ist da dran ?

Im Prinzip geht es um den wichtigsten Markt für
Siemens und Phoenix Contact     

Automatisierung bei den Autommobilhersteller
(das die einzigen die für gute Sachen auch das notwendige Geld haben)

VDA = Verband der deutschen Automobilbauer hatte die Nase voll
das schon wieder jeder Automatisierer RealTime-Ethernet-Standard erfindet und verbreitet. Darum haben sie sich für ProfiNet entschieden, und haben dies auch mit einen offiziellen Schreiben kundgetan.
(Das ist somit Tatsache). Somit ist ganz klar das in Europa (alleine durch die Marktanteile von Siemens) ProfiNet die Nr.1 wird. und das hat Beckhoff auch selber schon erkannt und kundgetan das EtherCat Nr.2 hinter ProfiNet werden wird.

Grosse Spieler bei den deutschen Automobilherstellern  sind nun einmal 
Siemens (SPS + Profibus) und Phoenix-Contact (Interbus, und seit einigen Monaten sind auch die SPS'en freigegeben und werden schon in diversen Projekten eingesetzt) Preiskonkurenz zu Siemens

Weiters möchten namentlich nicht genannte Automobilhersteller mindestens drei grosse Komponenten-Lieferanten für Profinet in der Zukunft haben.

Das sind neben Siemens und Phoenix Contact nun die ABB


----------



## Realtimer (3 April 2007)

Hallo,

ich wollte noch ein anderes Bussystem in die Diskussion einwerfen. VARAN von Sigmatek.  http://www.varan-bus.com. Ich habe das System vor etwa einem Jahr im Internet entdeckt und das hat damals sehr unprofessionell ausgesehen. Mittlerweile sieht auch der Internetauftritt sehr interessant aus und das System bietet einige Features, die bei anderen Systemen abgehen wie z.B. den asynchronen Direktzugriff auf einzelne Teilnehmer oder die Tatsache, dass sich die auch etwas bezüglich Spannungsversorgung über das Buskabel überlegen. Von der Geschwindigkeit dürfte es mit Ethercat nicht mitkommen, ist aber offensichtlich wesentlich schneller als Profinet und Powerlink und das Prinzip scheint sehr einfach zu sein.


----------



## mike_nl (4 April 2007)

*re:*

Hallo realtimer,

danke, den Link kannte ich noch nicht. Was mir aufiel bei der Seite war:

*Hot Plug in*Participants can be added or removed during operation

Wo bleibt da das 100% Safety Prinzip. Das kann so nicht gewaehleistet
sein, wenn ich z.B. an Pilz oder B&R Safety denke.

Weiter oben habe ich noch ein paar Dinge zu EPL gelesen, die so nicht
stimmen. Frage mich nur wie solche Infos an die Menschen gelangen
die Entscheidungen treffen muessen. Wer schuert das welche
Propaganda. Und das passiert in dem Geschaeft. Der Markt ist so
heiss umkaempft das manche vor nichts zuruekschrecken.

Naja halbwissen ist ja auch immerhin etwas. Und man kann Bananen
nicht mit Schrauben vergleichen. Da hinkt immer etwas. Ich denke
alleine dafuer wuerde sich ein Treffen lohnen. Nur ob die KnowHow
traeger von uns die da ja mal Antwort und Rede stehen muessten auch
die volle Wahrheit ans Licht brigen bezweifle ich.

Letztaendlich haengt es davon ab was ich wie Loesen will. Und... welcher
Hersteller gibt mir die meissten Prozente (selbst erlebt) und die
schoensten Flugreisen. Sowas kommt leider nur zu oft vor.

Gruss aus der Sonne traeumend ;-),

Mike


----------

