Das Split-Frame Processing Feature Pack ermöglicht die Verarbeitung mehrerer zyklischer EtherCAT-Aufgaben in separaten Anwendungs-Threads. Aus Anwendungssicht ist es damit möglich, EtherCAT-Prozessdaten über mehrere Threads hinweg zu strukturieren. So können Prozessdaten, die unterschiedliche Zykluszeiten erfordern, entsprechend behandelt werden.
Darüber hinaus kann auch die Verarbeitung der azyklischen Kommunikation an einen separaten Thread ausgelagert werden.

Eine typische Anwendung für das Split-Frame Processing Feature Pack wäre beispielsweise eine Aufgabe für Servoantriebe, die sehr schnelle Zykluszeiten erfordern, und eine weitere Aufgabe für E/A-Daten, die keine sehr schnelle Verarbeitung oder spezielle Zykluszeitanforderungen benötigen.

Mit dem EC-Engineer lassen sich Konfigurationen mit mehreren zyklischen EtherCAT-Aufgaben einfach erstellen:

Der Zeitablauf einer Anwendung, die Split-Frame Processing nutzt, würde wie folgt aussehen:

• Thread 0 läuft mit einer Zykluszeit von 250 Mikrosekunden und übernimmt die Verarbeitung der EtherCAT-Task 0. Dieser Thread sendet auch die Prozessdaten für alle anderen Tasks.
• Thread 1 läuft mit einer Zykluszeit von 500 Mikrosekunden und übernimmt nur die Verarbeitung der EtherCAT-Task 1.
• Thread Acyc läuft mit einer Zykluszeit von 1 Millisekunde und verarbeitet nur die azyklische Kommunikation sowie die Master-Management-Tasks.

Die Synchronisation von Systemkomponenten oder Produktionslinien mit mehreren EtherCAT-Segmenten kann mit verschiedenen Lösungen erfolgen:

• Synchronisation mit einer externen Grandmaster-Uhr unter Verwendung des IEEE 1588-Protokolls.
• Synchronisation durch ein Bridge-Gerät.

Je nach Anwendung gelten unterschiedliche Anforderungen an die Genauigkeit der Synchronisation. Für die Synchronisation von zwei Produktionslinien ist häufig eine Genauigkeit im Millisekunden Bereich ausreichend.
Wenn jedoch zwei oder mehr Motion-Control-Netzwerke synchronisiert werden sollen, kann es erforderlich sein, dass die Sync-Signale in allen Geräten genau zum gleichen Zeitpunkt anliegen (z. B. für eine netzwerkweite Kommutierungsinformation) – das bedeutet, dass eine Genauigkeit von besser als einer Mikrosekunde erforderlich sein kann.
Innerhalb eines EtherCAT-Segments kann der Distributed-Clocks-Mechanismus (DC) verwendet werden, um die Netzwerkgeräte zu synchronisieren. DC bietet eine Genauigkeit von deutlich besser als einer Mikrosekunde.
Das erste Gerät, das synchronisiert werden soll, wird als Referenzuhr für dieses Segment verwendet.
Die Synchronisation mehrerer EtherCAT-Segmente mit hoher Genauigkeit bedeutet, dass die DC-Referenzuhren in den Segmenten angepasst werden müssen.
Die führende Uhr wird als Grandmaster-Uhr bezeichnet. Dabei kann es sich um eine externe Zeitinformation handeln, z. B. einen GPS- oder DCF77-Empfänger (siehe Abbildung 27), aber auch um eine der DC-Referenzuhren.

Die Synchronisation von zwei oder mehr EtherCAT-Segmenten kann durch ein Bridge-Gerät erfolgen, wie in dieser Abbildung dargestellt.

Die Bridge verfügt über zwei EtherCAT-Anschlüsse (es werden zwei interne EtherCAT-Slave-Controller verwendet). Der primäre Port ist mit dem ersten Segment verbunden, der sekundäre Port mit dem zweiten Segment. Einer der beiden Ports kann als führende Zeitreferenz konfiguriert werden. Die Bridge kann die Zeitdifferenz berechnen und übermittelt den TimeControlValue an den Master. Der Master kann dann die Referenzuhr anpassen. Beim Start können die beiden Segmente zu unterschiedlichen Zeiten eingeschaltet werden. Das bedeutet, dass zwischen den beiden Segmenten eine absolute Zeitdifferenz besteht.

Zur Synchronisierung des sekundären Segments kommen zwei Softwarealgorithmen zum Einsatz:

• DCX: Synchronisierung der Referenzuhr mit dem Bridge-Gerät
• DCM: Synchronisierung des Master-Timers mit der Referenzuhr

Flexibiltät mit “Hot Connect”

Unter dem Begriff „Hot Connect (HC)“ versteht man bei EtherCAT zunächst einmal das An- und Abstecken von Slaves im laufenden Betrieb. Wobei dies nur ein mögliches Szenario ist. Viel häufiger besteht der Wunsch, dass auch ohne eine 100-prozentige Übereinstimmung zwischen Konfiguration (ENI Datei) und aktuell vorhandenen Slaves bzw. vorhandener Verkabelung, das System betrieben werden kann.

Folgende Anwendungsfälle sind dadurch realisierbar:
- Inbetriebnahme: Ein Teil der Anlage ist noch nicht verfügbar bzw. abgeschaltet.
- Optionale Teilnehmer, welche nicht zwingend vorhanden sein müssen (z. B. in der Messtechnik).
- Flexibiltät in der Verkabelung: Slaves können an unterschiedliche Ports angeschlossen werden (z. B. analog zu CAN).

Damit „Hot Connect“ funktioniert ist keine spezielle EtherCAT Funktion notwendig, vielmehr kann jeder EtherCAT Slave ein Mitglied einer HC-Gruppe sein. Eine HC-Gruppe muss nur eindeutig identifizierbar sein. Dazu werden in der Regel DIP Schalter verwendet. Die eingestellte Adresse erscheint dann im Station Alias Register oder an anderer Stelle innerhalb des Slaves Speichers. Beide Varianten werden vom EtherCAT Master unterstützt. Auch die Programmierung der Station Alias Adresse durch die Applikation über den Master ist möglich.

„Hot Connect“ ist als Feature Pack für den acontis EtherCAT Master ab der Version 2.0 verfügbar. Dabei erledigt der Stack alle Funktionen vollautomatisch im Hintergrund, ohne dass die Applikation eingreifen muss. Das Feature Pack bietet eine einfache Funktion zur Ermittlung der vorhandenen Slaves. Außerdem wird die Applikation durch eine Callback-Funktion (Notification) informiert, sobald ein Slave an- bzw. abgesteckt wird.

Zusätzliche Sicherheit gegen das Anstecken eines Slaves an einen falschen Port bietet die Funktion „Border Close“. Wird diese Funktion aktiviert, werden alle Ports mit Ausnahme der durch die Konfiguration zugelassenen Ports, in den Mode „Loop Closed“ geschaltet. Damit werden Slaves, die an diesen Ports angesteckt werden, einfach ignoriert und das System läuft völlig ungestört weiter.

Weitere Fragen zum Thema „Hot Connect“ beantworten wir gerne.

Um die Verfügbarkeit des EtherCAT-Systems zu erhöhen und für Ausfallszenarien vorzusorgen, kann über die MainDevice-Redundanzfunktion von acontis ein zweites, vollständig redundantes MainDevice-System zum Netzwerk hinzugefügt werden. Diese neue Funktion erstellt ein AKTIVES MainDevice und ein INAKTIVES Backup-MainDevice. Im Normalbetrieb leitet das INAKTIVE Backup-MainDevice Frames einfach mithilfe der optimierten Ethernet-Treiber von acontis für eine schnelle Paketweiterleitung durch das Netzwerk und zurück weiter:

Datensynchronisation und Kommunikation zwischen MainDevices

Durch schnelle Paketweiterleitung empfängt das AKTIVE MainDevice weiterhin alle Frames rechtzeitig für den nächsten Zyklus.
Das INACTIVE Backup-MainDevice hat Zugriff auf alle Prozessdaten. Es analysiert und modifiziert empfangene Frames und fügt nach zyklischen SubDevice-Frames selbst Frames hinzu. Das ACTIVE und das INACTIVE Backup-MainDevice können über Ethernet-over-EtherCAT (EoE) miteinander kommunizieren.

Failover

Wenn das AKTIVE MainDevice ausfällt, kann das INAKTIVE Backup-MainDevice die Kontrolle übernehmen und AKTIV werden. Da das INAKTIVE Backup-MainDevice die ganze Zeit über mit dem Netzwerk verbunden war, kann es nach dem Failover den Bus steuern, sobald es AKTIV wird:

Kabelredundanz mit MainDevice Redundanz

Kabelredundanz kann mit MainDevice-Redundanz kombiniert werden. Das AKTIVE MainDevice kommuniziert direkt mit einem Segment des EtherCAT-Slave-Netzwerks und indirekt über das INAKTIVE Backup-MainDevice mit dem anderen Segment des EtherCAT-Slave-Netzwerks:

Mit dem Mailbox-Protokoll Ethernet over EtherCAT (EoE) können Standard-Ethernet-Frames durch ein EtherCAT-Netzwerk getunnelt werden. Auf dieser Grundlage kann eine Kommunikation zu SubDevices mit lokal laufenden TCP/IP-basierten Anwendungen (z. B. Webserver) hergestellt werden. Immer mehr Hersteller von EtherCAT-Antrieben unterstützen diese Verbindung in ihren Tools zur Antriebskonfiguration und -optimierung.

acontis bietet alle erforderlichen Softwaremodule, um die TCP-Kommunikation zwischen einer Drittanbietersoftware unter Windows und einem EoE-fähigen EtherCAT-SubDevices zu ermöglichen. Auf dem Master-Controller muss lediglich der bewährte RAS-Server aktiviert werden. Der RAS-Server ist in der EC-Master-Kernlizenz enthalten und auf vielen Betriebssystemen verfügbar.

Viele der heute auf dem Markt erhältlichen EtherCAT-Produkte bieten Unterstützung für Ethernet over EtherCAT (EoE). EoE bietet eine bequeme Möglichkeit, ein EtherCAT-Gerät einzurichten und zu konfigurieren, ohne ein vollständiges EtherCAT-Netzwerk implementieren zu müssen. Viele Hersteller von EoE-fähigen EtherCAT-Geräten bieten ein Software-Tool zum Einrichten und Konfigurieren ihrer Produkte an. Einige Beispiele hierfür sind: Bosch Rexroth IndraWorks, Yaskawa SigmaWin+, Elmo Application Studio, und Copley CME2.

Für Entwickler und Anwender der EtherCAT-Master-Software EC-Master von acontis geht der Komfort dieser Hersteller-Tools verloren, da der Master-Controller, auf dem EC-Master läuft, vom Netzwerk getrennt werden muss, um einen Windows-Computer, auf dem das Software-Tool läuft, direkt mit dem EtherCAT-Gerät zu verbinden. Nach einigen einfachen Änderungen über das Hersteller-Tool muss der Master-Controller dann wieder angeschlossen werden. Um dieses Problem zu beheben, hat acontis sein EoE Gateway Tool für Windows veröffentlicht.

Mit dem EoE Gateway Tool bietet acontis eine bequeme Möglichkeit, den Master-Controller mit den EtherCAT-Geräten verbunden zu lassen und dennoch das Hersteller-Tool für die Einrichtung und Konfiguration zu nutzen. Dies wird erreicht, indem die Ethernet-Daten vom Tool durch den Master-Controller, auf dem EC-Master läuft, getunnelt und an das EtherCAT-Netzwerk weitergeleitet werden.

Dieses EoE Gateway Tool läuft im Hintergrund in der Windows-Taskleiste, sodass Sie sich ganz auf das Hersteller-Tool konzentrieren können, als wäre es direkt mit dem EtherCAT-Gerät verbunden.