Flusskontrolle

Die Flusskontrolle muss die Applikation übernehmen, es findet in der EL6695 kein Handshake-Mechanismus statt. Es kann allerdings in beiden PDO‑Betriebsarten ein Zähler eingeblendet werden, der bei jedem Schreibzugriff der Gegenseite inkrementiert wird: CoE‑Objekt 0xF640. Damit dieser Zähler als zyklisches PDO gemappt werden kann, ist er über einen StartUp-Eintrag wie folgt zu mappen:

Um das CoE Objekt 0xF640 mappen zu können, müssen als erstes wie im Kapitel „Grundlagen der Kommunikation“/ „CoE-Interface“, Abschnitt „Online/Offline Verzeichnis“ beschrieben, alle online CoE‑Objekte angezeigt werden. Anschließend können über den Reiter Process Data die PDO‑Daten vom Gerät neu geladen werden, sodass in der PDO‑Liste der Eintrag Active TX-PDOs-Map erscheint. Wird nun unter Sync Manager der Eintrag Inputs ausgewählt, kann unter PDO‑Assignment der Haken an dem Objekt 0x1A04 gesetzt werden und der Zähler von CoE‑Objekt 0xF640 wird ins Prozessabbild gemappt.

Datendurchsatz (Beispiel)

Im Folgenden ist der Datendurchsatz der EL6695 als Standardkonfiguration und mit zwei Optimierungsmethoden, durch Optimierung durch Synchronisation und durch Optimierung durch separates IO Update inklusive Synchronisation, grafisch dargestellt:

Um die konfigurierten Prozessdaten von einer EtherCAT-Seite zur anderen zu transportieren, wird eine von der Datenmenge abhängige Zeit benötigt.

Der interne Datentransport wird angestoßen durch das Auslesen einer Seite, vgl. dazu folgender Ablauf anhand der Abb. „EL6695 Ablauf Datentransport“:

• Die SyncManager 2 und 3 arbeiten im 3-Puffer Betrieb:
• Holt ein EtherCAT Master per EtherCAT Frame aus SyncManager 3, Puffer 3 Daten ab (A), startet die EL6695 sofort mit Beendigung dieses Auslesens (B) mit dem Kopieren von neuen Daten der Gegenseite in den nächsten freien Puffer; in diesem Fall Puffer 1. Das dauert die online auslesbare Zeit „Copy Time“. Die Begriffe „my“/ „remote“ beziehen sich dabei auf die „ich“-Seite, je nachdem ob man sich gerade im Online-CoE der primär- oder sekundär-Seite befindet.
• Dort liegen die Daten nun, bis sie von EtherCAT A abgeholt werden.
• Bei langer Zykluszeit kann es vorkommen, dass „relativ alte Daten“ fast einen ganzen EtherCAT‑Zyklus dort liegen. Der Transportzeitpunkt kann verschoben werden – durch diese Verzögerung/Delay kann das System so optimiert werden, dass Daten, die von System B in SM2 abgelegt werden, schon kurz danach intern zu Seite A, SM3 transferiert werden und der dann vorbeikommende EtherCAT frame A die Daten relativ frisch abholt.
  Dabei ist auf ein möglichst jitterarmes System auf Seite A und B zu achten.
  Das Verschieben kann eingestellt werden über
  - CoE 0x1C33:03 ShiftTime in ns
  - CoE 0xF830:01 nur im Online-CoE verfügbar, delay in µs

Im Folgenden eine exemplarische Messung mit folgendem Aufbau:
- PLC der Primärseite sendet einen Satz PDO
- EL6695 transportiert ihn auf die Gegenseite
- PLC der Primärseite holt die Daten ab und sendet sie ggf. verändert zurück
- EL6695 transportiert sie auf die Gegenseite
- PLC der Primärseite holt die Daten ab, zählt die PLC Zyklen bis hierher

In diesem Beispiel sind keine Optimierungen vorgenommen (PDO Delay, DC Synchronisation).

Soll eine hart gekoppelte zyklische Datenübertragung realisiert werden, empfiehlt sich eine DistributedClocks-Kopplung der beiden EtherCAT-Seiten, um Schwebungen beim Datentransport zu vermeiden.

Hinweis: bei der EL6695 sind faktisch immer zwei Feldbusse mit Ihren Zykluszeiten involviert. Nur bei optimaler Zeitplanung (DC Synchronisierung, ShiftZeiten angepasst) kann in etwa eine so kurze PC A → PC B Transportzeit realisiert werden, wie sie z.B. durch eine direkte Realtime‑Ethernet‑Strecke mit Publisher/Subscriber möglich ist. Auch dann ist die Optimierung nur für eine Richtung möglich und hat zusätzlich noch die Verzögerung der internen Transportzeit.