# Ethercat --- Verständnisproblem



## TomTom01 (5 November 2014)

Hallo liebe SPS Gemeinde!

in Bezug auf ein Studium haben wir das Projekt Feldbussysteme. Wir dürfen uns nun mit dem Thema "Ethercat von Beckhoff" auseinandersetzten.

Allerdings habe ich ein paar Verständnisprobleme mit dem Protokoll. (Allgemein)
Ich bin gerade den Header am zerpflücken, kann aber nicht richtig verstehen was für eine Aufgabe so ein "Header" in einem Telegramm hat.
Bin allgemein erst seit kurzer Zeit in diesem Gebiet. Ein klassischer Anfänger.

Wäre um jede Anmerkung froh!

Danke!

Gruß


----------



## RobiHerb (5 November 2014)

Ein Telegramm besteht aus Daten + Header.

Man kann sich das vereinfacht so vorstellen wie: Du schreibst einen Brief, das sind die Daten, den packst Du dann in einen Umschlag, das ist der Header.

Auf dem Umschlag steht dann der Absender, der Empfänger, ggf.ein Zeitstempel und so weiter. Alle diese Sachen kommen in den Header, damit die Übertragungs Medien (Post, Ethercat) wissen, was sie mit dem Rest (die Daten) machen sollen.

Wie der Header aufgebaut ist, regelt das Protokoll.


----------



## TomTom01 (5 November 2014)

Hallo RobiHerb!

erst mal Danke für die Verständlichen Antwort! 

OK, jetzt habe ich die Aufgabe von einem Header soweit verstanden...wenn ich mir mal allerdings die Grafik von 
so eine Ethernet Protokoll anschaue, steht der Header ja nicht vorne oder auch hinten, sondern irgendwo mittendrin?!
Oder habe ich da einfach ein Denkfehler?!


----------



## weißnix_ (5 November 2014)

Der Ethercat-Frame ist eingebettet in einen Ethernet-Frame. Wie es dort auch steht.
Blau sind die Standard-Daten (der Header) des Ethernet-Frames. In dessen Nutzdaten-Abschnitt ist dann der Ethercat-Frame eingebettet. Der besteht wiederum aus Header und Nutzdaten.

Zu unterscheiden ist jeweils bei so einer Betrachtung, ob Dein Nutzprotokoll in einem anderen transportiert wird. Dein Nutzprotokoll -hier Ethercat- wird ja über Ethernet transportiert. Die am Transport beteiligten Partner schauen nicht in die jeweiligen Nutzdaten. Für die ist nur -der zugehörige- Header interessant.
Also in Deinem Beispiel: Source und Destination sowie Steuerinformationen belegen die ersten 14Byte des Ethernet-Pakets und die Prüfsumme die letzten 4Byte. Dieser Header wird dann am Ziel entfernt. Am Ziel kommen also nur die Ethernet-Nutzdaten an. Dieses Ziel kommuniziert wiederum über ein Protokoll, weiß also: Die ersten 2 Byte sind der Header und der Rest wird dann entsprechend verarbeitet.


----------



## TomTom01 (5 November 2014)

Danke! 

....jetzt nur noch eine Frage, welche Daten stehen denn dann in Standard Daten von so einem Ethernet-Frame? Also als Source und Destination?
Quelle? Ziel?


----------



## weißnix_ (5 November 2014)

Guggst Du hier oder ausführlicher hier.
Quelle und Ziel sind hier als MAC-Adressen definiert.


----------



## TomTom01 (12 November 2014)

Servus! Jetzt muss ich mich nochmal melden ;-)

Wie kann ich das verstehen, das das Ethercat Protokoll in Bezug auf Ehternet nicht auf die Ebenen 3-6 schauen muss. (werden sie in Ethercat nicht benötigt)
Das soll doch auch ein Grund der Echtzeit sein, oder?

...tut mir leid aber irgendwie stehe ich im Moment so richtig auf dem Schlauch....


----------



## Marco Freihöfer (14 November 2014)

Hallo TomTom,

EtherCAT kommuniziert mittels MAC-Adresse. Die IP wird im regulären Verkehr nicht benutzt. Somit enfällt Layer 3 und 4 schon mal von Haus aus. In Layer 5 und 6 werden Protokolle wie FTP, SMTP, DNS und WWW bedient, wird im EtherCAT also auch nicht benötigt.

Ein Grund für die Echtzeit ist das allerdings noch nicht. Viel mehr spielt hier die Datensyncronisation eine Rolle. Diese wird mit dem sogenannten "distributed Clock" System durchgeführt. Aufgrund der Syncronisation sind sehr gerige Abweichungen (unter 1µs) möglich.


----------



## TomTom01 (19 November 2014)

Hallo!

das heißt aber, das die 7 Schichten bestehen bleiben, aber nicht alle benutzt bzw. ausgelesen werden müssen, oder?

Gruß Thomas


----------



## Marco Freihöfer (19 November 2014)

Hallo,

ja genau. Die Schichten bleiben natürlich bestehen. Das ISO7OSI Model ist ein Kommunikationsstandart. EtherCAT oder auch PROFINET bieten die Möglichkeit auch Ethernet einzubinden. Das funktioniert nur, da alle mit dem gleichen Prinzip (OSI Model) arbeiten.
Ethernet bedeutet IP. Hier werden dann also auch Schicht 3 und 4 eine Rolle spielen. 

Gruß Marco


----------



## TomTom01 (19 November 2014)

Vielen Dank!


----------



## TomTom01 (3 Dezember 2014)

Servus!

...noch ne kurze Frage, in welcher Schicht befinden sich nun die einzelnen Bits? Also z.B. Binäresignal der einzelnen Teilnehmer?
In der 7.?

Danke!


----------



## Marco Freihöfer (5 Dezember 2014)

Hallo TomTom01,

die Informationsbits liegen in der Dataunit nicht im Layer 7. Layer 7 ist vielmehr dafür verantwortlich die Information zu nutzen. Auf der Layer 7 Ebene findet die Dateneingabe sowie Ausgabe statt. 

Ich denke dieser Beitrag sollte sehr verständlich sein: http://de.wikipedia.org/wiki/Service_Data_Unit

Gruß Marco,

Indu-Sol


----------



## hovonlo (5 Dezember 2014)

Weiter oben stand die Aussage


> EtherCAT kommuniziert mittels MAC-Adresse.


Das stimmt nicht. EtherCAT benötigt keine MAC-Adressen und nutzt sie auch nicht. EtherCAT nutzt allein die Ethernet-Physik. Die Adressierung der Teilnehmer hängt allein an der physikalischen Reihenfolge, wie sie hintereinander gesteckt sind. Die Reihenfolge ist manchmal aber nicht ganz leicht zu erkennen, da diese letztlich über die Ports des (hauptsächlich eingesetzten) EtherCAT-ICs von Beckhoff definiert ist und von außen auf den Baugruppen nicht immer klar auf den ersten Blick erkennbar ist. Stark vereinfacht: Letztlich stellt EtherCAT für die zyklischen Prozessdaten ein Schieberegister dar.

Aber ganz wichtig: NIEMALS EtherCAT an eine übliche Ethernet-Netzwerkstruktur (Büro, ...) anschliessen. Abhängig von den verwendeten Switches kann dies zu einem kompletten Lahmlegen der IT führen.


----------



## Marco Freihöfer (5 Dezember 2014)

Hallo hovonlo,

auch das EtherCAT Telegramm benötigt eine Ziel und Source Adresse, ohne diese gäbe es keinen definierten Telegrammverkehr nach OSI Modell. Hier mal ein Telegrammitschnitt:

Die Teilnehmer werden nicht über MAC angesprochen, da wie Du schon sagst...Schieberegister.


----------



## TomTom01 (10 Dezember 2014)

Hallo Zusammen!

....Das ISO 7 Schichtmodel ist also nur ein bestandteil von dem Ethercat Frame?! Oder?

Kann mir das vielleicht einer mit Hilfe dem Bild auf Seite 1 erklären?
Wenn ich das verstanden habe, ist alles ok ;-)
Tut mir leid, aber solche Frames sind für mich komplettes Neuland......

Danke Gruß Thomas


----------



## Fliewatüüt (20 Dezember 2018)

*Anmerkung*

Hi Marco,  Das ist so nicht ganz richtig. Ethernet bedeutet nicht zwangsläufig IP. Der Ethernet Frame hat neben den beiden MAC Adressen auch ein Feld, in dem ein Code für den Typ der folgenden Daten steht. Heutzutage ist das meistens IP. Aber eben weder zwangsläufig noch immer. Microsoft hatte z.B. in der Anfangszeit Netbios über Ethernet gefahren. Auch ohne IP. Und EtherCAT ist wieder ein anderer Typ. Auch ohne IP.  Allerdings bietet EtherCAT seinerseits die Möglichkeit, auch IP-Pakete zu verschicken. Nennt sich IP over EtherCAT. Da sind die IP-Pakete aber nicht in einen Ethernet Frame eingebettet, sondern in einen EtherCAT Frame. Und dieser wiederum ist in einen Ethernet Frame eingebettet.  Und was das angeht, komme ich hier in Kürze auf eine Frage zurück. Wir haben hier die Aufgabe, Geräteparameter per TFTP hin und her zu schieben, über EtherCAT. Download geht, Upload nicht. Keiner weiss, warum. Aber hier werde ich erst mal versuchen, mich in die Materie etwas einzulesen. Aber wenn Jemand gute Hinweise hat, wo ich da was lesen sollte...  

Gruß Fliewatüüt *HonkHonk*

Nachtrag
Ich bin inzwischen etwas weiter. Und habe eine Frage zum TFTP Protokoll. Es sieht so aus, als ob bei einem Write Request zunächst keine Daten mitkommen. Das EtherCAT Gerät sendet ein ACK, das auch beim Client ankomt. danach sendet der Client die ersten max. 512 Bytes. Danach sollte das EtherCAT Gerät ein weiteres ACK schicken, mit der nächsten Blocknummer. Aber genau das unterbleibt. Es werden weitere ACKs geschickt mit Blocknummer 0. 

Was ich beobachten konnte, ist, dass ein Upload mit Dateien kleiner als 512 Bytes klappt. Wenn ich TFTP richtig verstanden habe, erwartet der Client in diesem Fall gar kein weiteres ACK vom EtherCAT Gerät, oder? Deshalb funktioniert das. Habe ich das richtig verstanden?

Wenn das richtig ist, muss ich nur noch rausfinden, wer hier die Blocknummer im ACK verhunzt: Das EtherCAT Gerät, oder der Master, der die standard IP/UDP Pakete in EtherCAT einpackt.


----------



## Fliewatüüt (20 Dezember 2018)

Hi  das mit dem "niemals an eine übliche Netzwerkstruktur (Büro) anhängen" ist eine vernünftige Empfehlung, aber keine technische Notwendigkeit. Probleme entstehen lediglich durch das immense Kommunikationsvolumen. Dadurch kommen andere Teilnehmer eben zu kurz. Bei Switches haben wir allerdings zusätzliche zur Paketvermittlung auch noch eine Leitungsvermittlung. Wenn die interne Kommunikation des Switches also leistungsfähig genug ist, kann das durchaus funktionieren. Anders wäre das, wenn man das Netz über einen Hub zusammenstöpselt. Dann breitet sich die Kommunikation immer über das gesamte Netz aus. Und bei dem massiven Volumen von EtherCAT gibt's dann eben wahrscheinlich Chaos.


----------

