# Ethercat - Master to Master Kommunikation



## Christian_ (3 August 2010)

Hallo Allerseits,

Ich wollte mal anfragen ob jemand schon etwas Erfahrung gesammelt hat und mir etwas Feedback geben kann.

Ich/Wir planen gerade den einsatz eines neuen Bussystems in unseren Anlagen. Dabei evaluieren wir auch Ethercat, ProfiNET und Sercos-III

Eine der wichtigsten elemente ist die Modulare bauweise der System. Im moment werden diverse Module über eigene Module Controler gesteuert die über einen CANbus asynchron untereinander kommunizieren.

Einer Überlegung wäre nun die MDC's (Module Controler) durch Ethercat Master zu ersetzten. Die Frage ist wie "fähig" zykluszeiten usw ist die Master zu master Kommunikation bei Ethercat ? z.B. das Polling eines Slaves durch einen "anderen master"

Bsp.

Hauptanlage - Modul1 - Modul2...

Modul2 möchte nun dedizierte Daten von einem Sensor des Modul1 haben. Sind die Typischen Master von z.B. beckhoff in der Lage auch neben ihrer "Mastertätigkeit" noch sensoren/systeme zu steuern ?

Eine Slave architektur scheidet zwischen den Modulen ziemlich aus und eine reine UpSTREAM DownSTREAM architektur ist auch nicht garantiert aka es werden totzyklen auftreten.

Gibt es andere Ethernet basierte busse die Dezentral arbeiten ?
Was würde sich für einen dem CAN ähnlichen Dezentralen aufbau am ehesten eignen (eurer Meinung nach?)
Sercos-III, Profinet, Ethercat ?

Danke fürs Feedback schonmal und Viele Grüße
Chris


----------



## trinitaucher (3 August 2010)

EtherCAT ist ein reines Master-Slave-System (Single-Master).
Es gibt von Beckhoff sog. "Bridge"-Klemmen, um zyklisch und synchronisiert Prozessdaten zwischen mehreren Master-Strängen auszutauschen. Aber da braucht man auch einen "Über"-Master:
http://www.beckhoff.de/default.asp?ethercat/el6692.htm (Topologie in der Grafki daneben)

Beckhoffs EtherCAT-Master ist eigentlich immer eine TwinCAT-Steuerung. Wenn man nicht gerade die Mindestversion TwinCAT I/O nimmt, ist somit immer eine Steuerungsfunktionalität mit drin.


----------



## Neals (3 August 2010)

Gibt auch noch das Realtime-Ethernet mit TwinCAT-Netzwerkvariablen.

Bei neueren Controllern gibt es auch die Möglichkeit in die Optionsschnittstelle eine EtherCAT-Slave Schnittstelle einbauen zu lassen.
Das wäre für einen CX5010 z.B. die Option CX5010-B110.


----------



## trinitaucher (3 August 2010)

Stimmt, über Real-Time-Ethernet mit Netzwerkvariablen ist auch eine echte Master-Master-Kommunikation möglich!
Ist dann aber ein proprietäres Kommunikationssystem, was nur zwischen TwinCAT-Steuerungen funktioniert
(... aber wer braucht schon was anderes )

Embedded-PCs mit EtherCAT-Slave-Schnittstelle gibts auch (bald?) noch andere:
http://www.beckhoff.de/default.asp?embedded_pc/cx8010.htm

Aber bei den Steuerungen mit EtherCAT-Slaves braucht man immer einen Master oben drüber. Also wieder kein echts Multi-Master-System.


----------



## Christian_ (4 August 2010)

Das Master/Slave problem war mir in teilen bereits bewusst, allerdings hatte ich nicht realisiert das ich für das Bridging auch wieder einen Master brauche 

Was das Realtime Ethernet mit TwinCat netzwerkvariablen angeht  das schaut schon mal sehr interesant aus werd mich dem Thema mal widmen müssen 

Vielen dank schon mal für die hilfreichen Antworten.

Grüße Chris


----------



## AndyS (4 August 2010)

*Master to Master*

Hi,

es kommt natürlich immer auf die Anforderungen an. Bei EtherCAT gilt es zu beachten, dass die Steuerungsvernetzungmöglichkeit (und damit auch der Austausch von Variablen zwischen Steuerungen), die EtherCAT bietet, nicht deterministisch oder echtzeitfähig ist, damit lassen sich dezentrale Anlagenteile nicht synchronisieren. 

Hier wird kein Echtzeit-Ethernet verwendet, sondern "normales", darüber wird dann ein bestimmtes Protokoll zum Austausch der Variablen gefahren. Damit ist auch eine Synchronisation der entsprechenden Anlagenteile nicht möglich, das geht meines Wissens nach (auf Basis eines genormten Standards) nur mit SERCOS III (das heißt dann da C2C und berücksichtigt sowohl die Synchronisierung als auch die direkte, nicht über eine zentrale Stelle umkopierten und damit mit zusätzlicher kommunikativer Totzeit behafteten Kommunikation mehrerer Steuerungen untereinander).

LG 
AndyS


----------



## Neals (4 August 2010)

AndyS schrieb:


> es kommt natürlich immer auf die Anforderungen an. Bei EtherCAT gilt es zu beachten, dass die Steuerungsvernetzungmöglichkeit (und damit auch der Austausch von Variablen zwischen Steuerungen), die EtherCAT bietet, nicht deterministisch oder echtzeitfähig ist, damit lassen sich dezentrale Anlagenteile nicht synchronisieren.



*bullshit*

Ich kann über die Bridge-Klemme sogar die Distributed Clocks der verschiedenen EtherCAT-Stränge synchronisieren und somit Ausgänge auf die !us! genau, synchron schalten lassen.
http://download.beckhoff.com/download/document/Application_Notes/DK9321-0110-0017.pdf


----------



## AndyS (4 August 2010)

*EtherCAT Master 2 Master*

Hi,

meine Aussage bezog sich auf das "EtherCAT Automation Protocol" EAP (http://www.ethercat.org/pdf/german/pcc_0409_etg_d.pdf), das verwendet UPD oder TCP. Natürlich kann man mit *zusätzlicher* Hardware auch einzelne Stränge über Distributed Clocks synchronisieren, das habe ich ja auch gar nicht behauptet, dass das nicht geht 

LG
AndyS


----------



## Neals (4 August 2010)

AndyS schrieb:


> Natürlich kann man mit *zusätzlicher*  Hardware auch einzelne Stränge über Distributed Clocks synchronisieren,  das habe ich ja auch gar nicht behauptet, dass das nicht geht



Naja, dein Satz sagt aber was anderes:



AndyS schrieb:


> Bei EtherCAT gilt es zu beachten, dass die  Steuerungsvernetzungmöglichkeit, die EtherCAT bietet, nicht  deterministisch oder echtzeitfähig ist...



Nun gut, fassen wir zusammen:

EAP: nicht deterministisch.
Realtime-Ethertnet: deterministisch
EtherCAT + Bridge: deterministisch


----------



## trinitaucher (4 August 2010)

Der Themenersteller sucht doch, soweit ich es mitbekommen habe, nach einer Möglichkeit, mehrere Steuerungen (bzw. Master-Geräte), über ein Multi-Master-Prinzip miteinander kommunizieren zu lassen.

EtherCAT in der aktuell verfügbaren Variante (ich kenne nur die Implementierung im TwinCAT) kann das in einem einzigen Netzwerk nicht. Dort geht nur Master-Slave.
Für Master-Querkommunikation müsste so oder so ein zweites Netzwerk aufgezogen werden.

Das CC von Sercos III, soweit ich es verstanden habe, behandelt erstmal grundsätzlich die Querkommuniaktion der Netzwerkteilnehmer in einem Netzwerk. Aber dieses Netzwerk wird trotzdem von einem einzige Master getriggert.
Will man unabhänigge Multi-Master-Kommunikaiton (wo auch mal ein Master ausfallen kann), darf man keinen "Über-Master" haben, der die zyklische Kommunikation kontrolliert.
Ich kann aber nicht nachvollziehen, wie das in einem C2C-Netzwerk geschieht. Laut der Beschreibung braucht man erstmal ein zweites Netzwerk, also *doch **Zusatzhardware*
Aber wer kontrolliert und synchronisiert dort den Datenaustausch? Wenn alle Master untereinander quasseln, wie kann man eine deterministische Kommunikation realisieren ohne einen "Über-Master"? Bei Profibus oder Modbus geht das ja über ein Token-Passing-Mechanismus. Den gibt es bei Sercos III ja nicht, bzw. bei keinem Ethernet-Feldbus.
Und was ist, wenn die Topologie unterbrochen wird? Wenn in einer Linien-Topologie zwischen den Master einer in der Mitte ausfällt?
... das muss man mir mal erklären.
Eine echte, unabhängige Multi-Master-Kommunikation sollte daher auch über Sterntopologien funktionieren. Geht bei Sercos III auch nicht.

EtherCAT bietet über die Bridge-Klemmen hoch deterministischen Datenaustausch und Netzwerksynchronisation. Aber nur mit einem "Über-Master" und Zusatzhardware.
So wie's aussieht, ist das zunächst mal bei Sercos III genauso. 

Datenaustausch ohne "Über-Master" bieten ansonsten Profinet, Modus-TCP und Ethernet/IP. Allerdings ohne Netzwerksynchronisation und auch nicht unbedingt mit harter Echtzeit im Sub-Millisekundenbereich.


----------



## AndyS (4 August 2010)

*Beckhoff Produkte vs. Ethercat Technologie*

Hi nochmal,

meiner Meinung nach wird hier im Speziellen wie auch im Allgemeinen nicht genau genug zwischen Beckhoff Produkten und Ethercat Technologie getrennt. 

Beispiel Brige-Klemme: Natürlich gibt es eine Bridge-Klemme von Beckhoff, die im Rahmen von TwinCat sicher auch super funktioniert, die zufälligerweise auch mit EtherCAT betrieben wird. 

Mir wäre aber keine allgemeingültige offene und nachimplementierbare Protokollbeschreibung dieses Teils der Technologie bekannt (wobei ich mich gerne eines besseren belehren lasse  ), um sie beispielsweise in einem eigenen EtherCAT-Slave oder mit einem eigenen Master zu implementieren und nicht darauf angewiesen zu sein, auf Beckhoff-Produkte zurückzugreifen (Thema second source...). 

LG
AndyS


----------



## trinitaucher (4 August 2010)

Beckhoff hat nunmal meines Wissens nach mit TwinCAT die umfangreichste Implementierung eines EtherCAT-Masters, und auch die größte Palette an Slaves.

Die Bridge-Klemme ist eigentlich nur ein "normaler" Slave, der über CoE konfiguriert wird. Kann also an jedem anderen Master genauso laufen.
http://infosys.beckhoff.com/index.p.../html/bt_el6692_objectdescription.htm&id=5656
Die Klemme bedient sich nur den Mechanismen des EtherCAT-Protokolls. Stellt Prozessdaten zur Verfügung (die in diesem Fall vom anderen Strang kommen) und ggf. einen Zeitwert, den dann der Master als Referenzzeit für die verteilten Uhren nutzen kann.

Diese Art der Synchronisierung hat erstmal nichts mit einer spezielle Beckhoff Variante zu tun, sondern kann von anderen Mastern genau verwendet werden. [edit]
Außerdem ist die Denkweise bei EterhCAT etwas anders. Nicht der Master synchronisiert, sondern die Slaves synchronisieren sich untereinander. Von daher kann ein Slaves beliebige Funktionalitäten erfüllen. In diesem Fall ebend Prozessdatenaustausch mit "extern" und Bereitstellung einer Systemzeit.
... und das kann man sich zur Not bestimmt auch in einem eigenen Slave zusammenbasteln.

[edit]


AndyS schrieb:


> Mir wäre aber keine allgemeingültige offene und nachimplementierbare Protokollbeschreibung dieses Teils der Technologie bekannt (wobei ich mich gerne eines besseren belehren lasse  ), um sie beispielsweise in einem eigenen EtherCAT-Slave oder mit einem eigenen Master zu implementieren und nicht darauf angewiesen zu sein, auf Beckhoff-Produkte zurückzugreifen (Thema second source...).


Nochmal kurz zur Erklärung wie das bei EterhCAT mit der Synchronisierung funktioniert:
Dem Master wird ein Slave als Referenzuhr bekannt gegeben. Der Master ermittelt die Laufzeiten des Telegramms zwischen den Slaves mit Distributed Clocks und errechnet die notwendigen Shift-Zeiten im Verhältnis zur Referenzzeit. Diese Shift-Zeiten werden den anderen Slaves bekannt gegeben.
Fortan führen die Slaves ihre Aktionen erst dann aus, wenn ihre eingestellte Shift-Zeit nach dem Eintreffen des Telegramms vorüber ist.
Der Master ist einzig für die (rechtzeitige) Verteilung der Telegramme und das Nachregeln der Slave-Uhren verantwortlich. Die Slaves kontrollieren selbsstständig, wann sie was machen sollen.
Und die Bridge-Klemme ist nur ein Slaves, der neben Prozessdaten noch eine Uhrzeit (von extern) bereitstellt. Wie der Master diese Datenv erwendet ist implementierungsabhängig. Hat aber mit dem Protokoll an sich nichts zu tun.

Mich würde bei Sercos III interessieren, wie der Kommunikationsablauf im "C2C"-Verfahren vonstatten geht (siehe mein Post zuvor).

Ach übrigens:
Es gibt da ja noch Ethernet-Powerlink. Dort ist angeblich auch direkte Querkommunikation zwischen Teilnehmern möglich. Aber auch hier weiß ich nicht, ob Master-Master-Kommunikation überhaupt möglich ist, und wie sich die "Managing Nodes" das ggf. untereinander koordinieren.


----------



## Christian_ (5 August 2010)

trinitaucher schrieb:


> Mich würde bei Sercos III interessieren, wie der Kommunikationsablauf im "C2C"-Verfahren vonstatten geht (siehe mein Post zuvor).
> 
> Ach übrigens:
> Es gibt da ja noch Ethernet-Powerlink. Dort ist angeblich auch direkte Querkommunikation zwischen Teilnehmern möglich. Aber auch hier weiß ich nicht, ob Master-Master-Kommunikation überhaupt möglich ist, und wie sich die "Managing Nodes" das ggf. untereinander koordinieren.


 

Sercos III benutz eine art Master Master zur Querkommunikation so wie ich das bisher aus den Specs/daten verstehe funktionieren die Master in einer Line dann im Prinzip genauso wie Die Slaves zu einem master.

D.h. Der MasterMaster bereitet dann AT's (Aknowledge telegramms) for die Zur Querkommunikation in beide Richtungen genutzt werden. Da in Sercos III Telegramme bei hin UND rückweg (Entgegen EtherCAT) bearbeitet werden ist UP Down und Down Up in der Line quasi das gleiche.

Ethernet Powerlink benutzt keine Switches sondern Hubs und sendet daten im broadcast verfahren, d.h. jeder Teilnehmer "hört" alle daten mit daher ist dort eine Querkommunikation quasi schon fest eingebaut, erhöht natürlich das Datenaufkommen bei vielen teilnehmern entsp.

Beides noch ohne gewähr da ich mich immer noch in die diversen Bus-systeme einarbeite 

Grüße Chris


----------



## trinitaucher (5 August 2010)

Christian_ schrieb:


> Sercos III benutz eine art Master Master zur Querkommunikation so wie ich das bisher aus den Specs/daten verstehe funktionieren die Master in einer Line dann im Prinzip genauso wie Die Slaves zu einem master.
> 
> D.h. Der MasterMaster bereitet dann AT's (Aknowledge telegramms) for die Zur Querkommunikation in beide Richtungen genutzt werden. Da in Sercos III Telegramme bei hin UND rückweg (Entgegen EtherCAT) bearbeitet werden ist UP Down und Down Up in der Line quasi das gleiche.
> 
> Ethernet Powerlink benutzt keine Switches sondern Hubs und sendet daten im broadcast verfahren, d.h. jeder Teilnehmer "hört" alle daten mit daher ist dort eine Querkommunikation quasi schon fest eingebaut, erhöht natürlich das Datenaufkommen bei vielen teilnehmern entsp.


Das ist mir alles klar, aber der tatsächliche Kommunikationsablauf ist mir ebend nicht klar.

Normalerweise gibt's bei Sercos III und Ethernet-Powerlink immer einen einzigen Master, der die Telegramme verschickt und somit die Kommuniaktion triggert.
Was ist aber nun bei mehreren Mastern? Da müssen die Master untereinander sich doch abstimmen, wer wann ein Telegramm verschicken darf. Sonst ist doch die Deterministik nicht gegeben. Oder man braucht wieder einen einzigen Master, der die Oberhand hat.
Bei Sercos III mit Vollduplex könne beide Master zwar ungestört Telegramme versenden, die "Takte" der Versendung unterscheiden sich aber doch bestimmt, bzw. wer gibt den Takt vor?
Falls es solche Takgeber nicht gibt, ist die Kommuniaktion nicht mehr synchronisiert.
Und bei Linientopologie zwischen den Mastern darf trotzdem ein Gerät "in der Mitte" nicht ausfallen. Sterntopologie ist ja nicht möglich.

Wenn Powerlink generell nur Hubs verwendet, ist doch auch essig mit Voll-Duplex. Dann kann's doch schon gar keine mehreren Master geben, die unabhängig selbstständig Telegramme verschicken können.
Also wieder ein "Single"-Master, der die Sendezeiten steuert.


----------



## Christian_ (5 August 2010)

Also Sercos III hat ja einen "Über"Master der Die Kommunikation unter den Mastern Regelt, wie diese allerdings Synchron mit den Slaves der Master synchron gehalten wird ist mir auch noch nicht 100 Prozent klar.

Was Ethernet-Powerlink angeht hast du völlig recht. Es gibt nur EINEN master den Sogenanten MN (Managing Node) Dies ist der Einzige Node der unaufgefordert daten senden darf. Der Startet einen Zyklus und Pollt dann nach einander die einzelnen Nodes die diesen zyklus dran sind (müssen nicht zwingend alle sein) Jeder Node der gepollt wurde antwortet dann mit seinem whatever und da alle mithören hast du in dem moment eine Art Wer immer die daten braucht nimmt sie sich situation. dann ist der Nächste Node dran usw. Wenn die Phase vorbei ist und noch platz im Cycle dann kommen noch Asynchrone sachen wir TCP/IP und stuff.

Die Cycles sind natürlich entsprechend länger weil eben kein VollDuplex gegeben ist.


----------



## trinitaucher (5 August 2010)

Christian_ schrieb:


> Also Sercos III hat ja einen "Über"Master der Die Kommunikation unter den Mastern Regelt, ...


Interessant. Auch bei der C2C-Kommunikation? Man kann das aus den vielen Hochglanzbroschüren immer nie so erkennen.


----------



## Christian_ (5 August 2010)

Jup so lese ich das aus den technical specs und so:

Siehe auch

PDF: http://www.sercos.com/news/pdf/description_of_sercos_interoperability_demo.pdf

letzter Abschnitt erste seite:



> The second system consists of a SERCOS III controller from Bosch Rexroth. This controller operates as a SERCOS III master in the controller-to-controller communication, with the other two controllers in the demo as slaves. It also controls two Bosch Rexroth SERCOS III servodrives.


 
Ausserdem noch: http://www.sps-magazin.de/?inc=artikel/article_show&nr=29462

Der Abschnitt Funtkionsweise ist hier interesant. Zusammengefasst sagt er, C2C Kommunikation findet in den AT (Aknolwedge telegramms) statt welche nach der Sercos III Spec immer von einem einzigen Master gesendet und seinen slaves bestückt werden. Hier also der MasterMaster oder eben Über-Master an dem die anderen Master als Slaves hängen die dann aber wieder Slaves haben können.


----------



## trinitaucher (5 August 2010)

Ah, danke!

Also funktioniert das bei Sercos III im Prinzip genauso wie's bei EtherCAT (Beckhoff) mit den Bridge-Slaves geht.


----------



## AndyS (9 August 2010)

trinitaucher schrieb:


> Ah, danke!
> 
> Also funktioniert das bei Sercos III im Prinzip genauso wie's bei EtherCAT (Beckhoff) mit den Bridge-Slaves geht.



Im Prinzip schon, allerdings sind die Philosophien, wie die Synchronisation zustande kommt komplett verschieden, was sich auch in der Topologie wiederfindet. 

Bei EtherCAT wird eine Art Systemzeit zyklisch (? das scheint in der Verantwortung des Masters zu liegen) über ein RMW abgeglichen, diese wird wohl typischerweise durch einen Slave bereitgestellt (soweit ich es verstanden habe).

Bei SERCOS III geht die Synchronisation vom Master aus, er sendet in jedem Buszyklus ein Synchronisationstoken (MST), auf den sich die Slaves aufsynchronisieren. 

Koppelt man jetzt mehrere Netzwerke, so besteht die Notwendigkeit, die Systemzeit bzw den Sychronisationstoken von einem in das andere Netzwerk zu "übertragen". Da EtherCAT keine spezielle Hardware im Master erfordert, und damit den Jitterzeiten von Software (im Master) unterliegt, wird hier eine Slave-Brigde benötigt, die vom einen ins andere Netzwerk die Systemzeit überträgt (interessant wäre hier für mich, wie mit unterschiedlichen bereits vorhandenen Systemzeiten in den Netzwerken umgegangen wird). Bei SERCOS III werden die Token direkt durch den Master übertragen, der ja dann Slave oder Master in einem übergeordneten Ring ist, der kann über definiertes "Ziehen" dann seinen Ring auf den übergeordneten Ring aufsynchronisieren.

Gruß
AndyS

PS: Wie immer, wenn ich etwas falsch verstanden habe, ich lass mich gerne belehren, bin ja noch jung und interessiert  .


----------



## trinitaucher (9 August 2010)

Du hast's richtig erkannt. Bei EtherCAT wird von einem Slave die Referenzzeit genommen. Ob dieser Salve seinerseits diese Zeitbasis von seinem eigenen Quarz nimmt, oder von einem übergeordneten System (bei gekoppelten Systemen) bekommt, ist dem Master, der die Uhren seines Systems einstellt und nachregelt erstmal egal. Übergeordnete Zeitbasen bekommt man z.B. über diese Bridge- oder von einer IEEE-1588-Klemme.
  Im übergeordneten Strang gibt's dann wiederum einen Slave, der die Referenzuhr spielt. So kann diese Referenzzeitbasis an alle verbundenen Stränge verteilt werden.
  Man könnte wohl auch einen Master als Referenzuhr nehmen. Da der aber ein Softwareprodukt ohne hochgenaue Hardware-Uhr ist, werden die Slaves als Referenzuhren bevorzugt.
  Es muss bei EtherCAT kein fortlaufender, hoch deterministischer Telegrammversand stattfinden, da die Slaves ihre Aktionen in Abhängigkeit vom berechneten Synchronisationszeitpunkt selbstständig durchführen.
  Das Telegramm mit den Daten muss nur rechtzeitig  den Slave erreicht haben, d. h. vor dem errechneten Sync-Inpuls. Ob der Telegrammversand jittert (sprich der Master jittert) ist den Slaves egal.

  Wenn bei Sercos III nun der Master ein Sync-Telegramm sendet, wie wird denn die Laufzeit des Telegramms berücksichtigt, so dass die Slaves ihre Aktionen synchronisiert durchführen? Soweit ich weiß, gibt's in den Slaves keine verteilten Uhren alla EterhCAT, oder doch?


----------



## AndyS (9 August 2010)

*Synchronisation SERCOS III*

Danke für die Infos...



trinitaucher schrieb:


> Wenn bei Sercos III nun der Master ein Sync-Telegramm sendet, wie wird denn die Laufzeit des Telegramms berücksichtigt, so dass die Slaves ihre Aktionen synchronisiert durchführen? Soweit ich weiß, gibt's in den Slaves keine verteilten Uhren alla EterhCAT, oder doch?




Der Vollständigkeit halber:

Es existiert bei SERCOS III eine Laufzeitkompensation für die Synchronsationsmarken. Hierzu wird vereinfacht gesprochen die Gesamtlaufzeit gemessen und auf den Slave individuell heruntergebrochen (für jeden logischen Ring einzeln, ist notwendig, da ja in Ringverkabelung zwei entgegensätzlich laufende logische Ringe existieren und die Synchronisationsmarken der Ringe beim Slave zu unterschiedlichen Zeitpunkten ankommen). Das hat bei Ringverkabelung den Vorteil, dass wenn eine Synchronisationsmarke aus irgendeinem Grund ausfällt (z.B. bei Ringbruch) bleibt die Synchronisation erhalten.

Auf Basis dieser Marken wird im Slave eine telegrammebenenunabhängige und slaveübergreifende Zeitebene aufgezogen, auf die sich dann die Zeitpunkte für Sollwert-Gültigkeit und Istwert-Erfassung netzwerkglobal beziehen. 

Gruß
AndyS


----------

