EAP Telegramm Struktur

Ein EAP Telegramm kann per Ethernet (Ethertype = 0x88A4 entspricht dem EtherCAT Protocol) oder per UDP/IP (UDP-Port 0x88A4) übertragen werden. Wenn EAP auf dem EtherCAT Protocol basiert, sind die EAP-spezifischen Telegrammteile in den Nutzdaten des EtherCAT Protocols eingebettet.

Das EAP Telegramm besteht aus einem Process Data Frame Header und einem oder mehreren ProcessData (PD). Ein PD ist die Haupteinheit beim Datenaustausch via EAP. Ein PD setzt sich zusammen aus einem sogenannten PDO Header und mindestens einer Process Variable (PV). Die Process Variables eines PD zusammengenommen bilden das ProcessDataObject (PDO). Vgl. dazu folgende Abbildung.

EAP Telegramm Struktur 1:

Der Process Data Frame Header

Der Process Data Frame Header besteht aus fünf Feldern (vgl. Zeile 2 und 3 in der Abbildung oben). Das letzte Feld (EAP SM) erweitert das NWV-Telegramm von TwinCAT 2 im Hinblick auf die Inhalte. Dieses Feld beinhaltet unter anderem Informationen zum aktuellen Zustand des EAP Gerätes.

Publisher ID
Anhand der Publisher ID wird der Sender eines Telegramms identifiziert. Sie enthält die AMS NetID des Absenders. Wenn bei einem Empfänger konfiguriert ist, dass dieser ausschließlich Telegramme von einem bestimmten Absender verarbeiten soll, wird anhand des Feldes Publisher ID geprüft, ob das EAP Telegramm von diesem Absender stammt.

Cnt PDO
In diesem Feld steht die Anzahl der im Telegramm enthaltenen ProcessData, damit der Empfänger das Telegramm vollständig verarbeiten kann.

Cycle
Der Wert dieses Feldes wird bei jedem Taskzyklus des Absenders inkrementiert. Auf der Seite des Empfängers kann der Inhalt dieses Feldes als Sequenznummer verwendet werden, um z.B. zu prüfen, ob ein Telegramm verloren ging. Beim Polled Data Exchange Modus sollte serverseitig dieses Feld überwacht werden.

Res
Reserviert für zukünftige Erweiterungen.

EAP SM
Dieses Feld setzt sich aus 4 Subeinträgen zusammen.

  • Res: Reserviert für zukünftige Erweiterungen.
  • Toggle: Dieses Bit wird für jedes neue EAP Telegramm umgeschaltet.
  • Err: Dieses Feld zeigt an, ob ein Fehler bei der EAP State Machine aufgetreten ist.
  • State: Dieses Feld enthält den Wert für den aktuellen Zustand der EAP State Machine.
  • 1 : Init
  • 2 : Pre-Operational
  • 4 : Safe-Operational
  • 8 : Operational

Andere Werte als diese sind nicht erlaubt

Der PDO Header

Der PDO Header besteht aus 4 Feldern, von denen jedes Feld eine Datenlänge von 2 Byte hat (vgl. Zeile 3 und 4 in der Abbildung oben).

PD ID
Die PD ID (16 Bit) dient zur globalen Identifizierung der EAP Variablen und sollte eindeutig im Netzwerk sein.

Auswahl der ProcessData Identifier (PD ID)

Um eine eindeutige Zuordnung zu erreichen wird empfohlen, für jede Datenübertragung zwischen zusammenhängenden PCs unterschiedliche IDs zu verwenden.
Begründung: In der folgenden Abbildung erhält PC 2 in Box 2 (Subscriber) nicht nur die vorgesehenen Variable aus Box 2 (Publisher) mit der ID = 8 von PC 1, sondern, da als Broadcast(!) gesendet, auch die Variable aus Box 2 (Publisher) von PC 3. Eine Unterscheidung ist in PC 2 dann nicht mehr möglich!

EAP Telegramm Struktur 2:

Version
In dieses Feld kann eine Versionsnummer für das PD eingetragen werden. Welchen Einfluss die Version bei der EAP Kommunikation hat, wird im Kapitel Kommunikationsmethoden im Abschnitt Vermittlungsprotokolle erläutert. Die Versionsnummer sollte konsequent erhöht werden, wenn mindestens eine der folgenden Änderungen am ProcessData vorgenommen werden:

  • Die Datenlänge des ProcessData wird verändert
  • Der Datentyp einer Variable des ProcessData wird verändert
  • Die Reihenfolge der Variablen in einem PDO wird verändert

Length
Dieses Feld enthält die Länge des ProcessData in Bytes. Die Länge des Process Data Header selbst ist nicht darin enthalten.

Quality
Der Wert dieses Feldes zeigt das Alter der ProcessData in der Einheit [100 µs] an, wenn der Wert zwischen 0x0 und 0xEFFF liegt. Ein Wert größer oder gleich 0xF000 bedeutet, dass das ProcessData ungültig ist.

Die Process Variable (PV)

Die Process Variable enthält die tatsächlich zu übertragenen Daten (vgl. Process Var in Zeile 4 der ersten Abbildung oben). Die Datenlänge einer PV darf nur so groß sein, dass das gesamte EAP Telegramm nicht größer als 1514 Byte wird.

Größenberechnung eines EAP Telegramms

Die Summe der Längen aller Header und aller Publisher Variablen darf die Grenze von 1514 Bytes nicht überschreiten. Das abgebildete EAP Telegramm (siehe folgende Abbildung) hat eine Gesamtgröße von
14 + 28 + 2 + 12 + 8 +120 + 72 + 12 + 8 + 100 = 376 Bytes.

EAP Telegramm Struktur 3:

(Diese Berechnung inkludiert 28 Bytes für den UDP/IP Hdr. Die 28 Bytes stehen bei reiner Ethernet Kommunikation für Daten bereit.)

Datendarstellung auf unterschiedlichen Plattformen

Zu beachten ist, dass einfache wie komplexe Daten (WORD, ARRAYs, REAL, STRING, benutzerdefinierte Strukturen) auf unterschiedlichen Plattformen intern unterschiedlich dargestellt werden. x86-Plattformen arbeiten im Byte-Alignment, andere (ARM) im 2- oder 4-Byte-Alignment.
Das bedeutet, wenn eine komplexe Struktur jeweils in einem x86/PC-PLC-Projekt und einem ARM-PLC-Projekt angelegt wird, diese jeweils eine andere effektive Größe und einen anderen inneren Aufbau haben kann.

EAP Telegramm Struktur 4:

Im Beispiel (siehe Abbildung oben) ist die Struktur im PC2 größer als im PC1. Außerdem passen die Word- und Real-Variablen nicht zueinander, da im PC1 an jeder Byte-Position eine Variable beginnen kann, im PC2 jedoch nur an jeder geradzahligen Byte-Position.

Es wird empfohlen beim Aufbau von Strukturen folgende Regeln zu beachten, damit keine Größenunterschiede durch das Alignment verursacht werden:

  • zuerst alle 4-Byte-Variablen (müssen auf einer durch 4 teilbaren Adresse liegen)
  • dann alle 2-Byte-Variablen (müssen auf einer durch 2 teilbaren Adresse liegen)
  • dann alle 1-Byte-Variablen

Weitere Empfehlung:

  • wenn der Datentyp STRING(x) in einer SPS verwendet wird, dann gehört die Nullterminierung des Strings ebenfalls zum String selbst, so dass gilt: x+1 muss durch 4 teilbar sein. Andernfalls liegt kein 4-Byte-Alignment vor.
  • obige Regeln gelten auch für Substrukturen.

Weitere Hinweise sind im Beckhoff Informationssystem zu finden unter „TwinCAT 3/TExxxx | TC3 Engineering/PLC/PLC/Programmierreferenz/Datentypen/Benutzerdefinierte Datentypen/Strukturen“ oder „TwinCAT 3/TExxxx | TC3 Engineering/PLC/PLC/Programmierreferenz/Deklaration/Alignment“.

Verwendung von Busklemmen-Controllern (BCxxxx, BXxxxx)

Fließkommazahlen (Datentyp REAL) können auf Busklemmen-Controllern (BCxxxx, BXxxxx) nicht übertragen werden, da die Darstellung einer Fließkommazahl auf einem Busklemmen-Controller von der auf einer x86-Plattform abweicht.
Für vorzeichenbehaftete Werte kann z.B. der Datentyp SINT verwendet werden.