Ethercat - Master to Master Kommunikation

Christian_

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Zuletzt bearbeitet:
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.
 
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 :ROFLMAO:)

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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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:

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
 
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. :rolleyes:

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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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]
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.
 
Zuletzt bearbeitet:
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
Zuletzt bearbeitet:
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 ;) .
 
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?
 
Zurück
Oben