EAP-Telegrammstruktur

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-Telegrammstruktur 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.

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.

EAP-Telegrammstruktur 2:

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-Telegrammstruktur 3:

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:

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.

EAP-Telegrammstruktur 4:

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-Telegrammstruktur 5:

(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-SPS-Projekt und einem Arm®-SPS-Projekt angelegt wird, diese jeweils eine andere effektive Größe und einen anderen inneren Aufbau haben kann.

EAP-Telegrammstruktur 6:

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:

Weitere Empfehlung:

Weitere Hinweise finden Sie im Beckhoff Information System in der Dokumentation PLC: Strukturen oder 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.