Es liegt normalerweise in der Natur der Dinge, dass Wachstum auch eine Zunahme an Komplexität bedeutet. Der Trend der zunehmenden Verwendung von Industrial Ethernet stellt jedoch nicht nur neue Anforderungen, sondern bietet auch neue Möglichkeiten und teilweise sogar Vereinfachungen, wie der folgende Fachartikel am Beispiel von EtherCAT aufzeigt.
Bereits seit Jahren hält Ethernet als Kommunikationsstandard auch in der Industrie verstärkt Einzug. Dabei ist auch immer häufiger von EtherCAT die Rede. So kann man beobachten, wie vermehrt Neuentwicklungen von Automatisierungsanlagen auf der Basis von EtherCAT geplant werden. Dieser Umstieg bedeutet schnellere Kommunikation über größere Entfernungen und ist so mit einer Vielzahl von Vorteilen verbunden.
Wie jedoch steht es um die Einfachheit der Anwendung? Wie kann eine Automatisierungslösung auf der Basis von EtherCAT mindestens so einfach handhabbar sein, wie frühere Lösungen? Wie sollte eine Lösung aussehen, die nur geringen Einarbeitungsaufwand erfordert, schnellen Erfolg garantiert und so dem Anwender Zeit und Kosten einspart? Wie kann man den höchstmöglichen Grad an Effektivität gewinnen, um eine Anwendung schnell und produktiv realisieren zu können? Diesen Fragen wird im vorliegenden Artikel anhand des EtherCAT Masters eines Berliner Software-Unternehmens nachgegangen.
Der Kithara EtherCAT Master ist eine Entwicklung, die grundlegende Funktionen enthält, die in anderen Lösungen so nicht oder nur eingeschränkt zu finden sind und im Folgenden erklärt werden. Die einfache Anwendbarkeit befähigt in den meisten Fällen den Programmierer, sich sehr schnell mit der eigentlichen Realisierung seiner Applikation befassen zu können, ohne umfangreichen Einarbeitungsaufwand zu betreiben. Für spezielle Einsatzfälle ist es jedoch auch möglich, sehr fein in die Mechanismen einzugreifen. Dies erfordert dann natürlich auch einen höheren Aufwand seitens des Programmierers.
Es handelt sich um eine echtzeitfähige Lösung unter Windows. Die Echtzeitfähigkeit wird von einer speziellen Windows-Echtzeiterweiterung bereitgestellt. Diese bietet auch PC-basierte Echtzeit-Timer mit mehreren Kilohertz und verschiedene hardwarenahe Zugriffsmechanismen, einschließlich solcher zum Zugriff auf PCI-Karten oder USB-Geräte. Um die Echtzeitfähigkeit des EtherCAT Masters zu erreichen, sind zwei Voraussetzungen zu erfüllen: Zum einen muss die Netzwerkverbindung ein verzögerungsfreies Senden und eine unmittelbare Reaktion beim Empfang von Ethernet-Frames ermöglichen. Hierzu sind auf jeden Fall die langsamen Original-Treiber von Windows zu ersetzen und die Netzwerk-Hardware ist mit optimierten Treibern direkt anzusprechen. Zum anderen ist die anwenderspezifische Steuerungssoftware, die in den meisten Automatisierungsanwendungen zyklisch zeitäquidistant ausgeführt werden muss, in Echtzeit zu betreiben.
Im Folgenden wird davon ausgegangen, dass der Anwender die Steuerungssoftware selbst in C/C++ oder Delphi realisiert. Auf der Basis dieser Programmiersprachen kann der Entwickler seine Echtzeit-Routinen in seiner gewohnten Entwicklungsumgebung als Teil der Steuerungsapplikation erstellen. Dabei erfolgt die eigentliche Entwicklung der Steuerungssoftware komfortabel auf der Anwendungsebene, während diese später auf der Kernel-Ebene in Echtzeit ausgeführt wird. Auf diese Weise stehen dem Programmierer sämtliche Mechanismen als Teil einer Funktionsbibliothek zur Verfügung, zu der auch die Funktionen des EtherCAT Masters gehören.
Zunächst einmal soll die Art der Konfiguration betrachtet werden. Im einfachsten Fall ruft der Anwender eine Funktion zum Öffnen des EtherCAT Masters auf, die den Zugang zur Netzwerkkarte herstellt, die angeschlossene EtherCAT-Topologie vollständig analysiert und daraufhin eine Deskriptorstruktur zurückliefert, die alle angeschlossenen EtherCAT-Slaves (also z.B. die EtherCAT-I/O-Klemme) umfassend beschreibt. Der Anwender kann dieser Deskriptorstruktur u.a. folgende Informationen entnehmen: Oberstes Glied der Deskriptorstruktur ist der so genannte Master-Deskriptor, der u.a. angibt, wie viele EtherCAT-Slaves angeschlossen sind und einen Zugriff auf die jeweiligen Slave-Deskriptoren ermöglicht. Diese wiederum beschreiben den Slave anhand von Vendor- und Produkt-ID, Typ, Namen und einigen beschreibenden Elementen. Sie verweisen weiter auf die Deskriptoren der einzelnen Prozessdatenobjekte (PDO) und Servicedatenobjekte (SDO) und diese wiederum beschreiben jede einzelne, in ihnen enthaltene Variable mit Namen, Datentyp und Bitlänge.
Der Anwender kann also nach nur einem Funktionsaufruf zum Öffnen des EtherCAT Masters bereits vollständig das angeschlossene EtherCAT-Netz nach seinen eigenen Vorstellungen analysieren. Allein hier zeigt sich eine signifikante Vereinfachung in der Handhabung gegenüber vielen anderen Lösungen. Tests auf Vorhandensein verschiedener Slavetypen, die Lokalisierung eines bestimmten Slaves und der Vergleich mit einer vorgegebenen Topologie sind auf dieser (White-Box-) Basis ebenso einfach möglich wie beispielsweise die grafische Präsentation der Netzwerkstruktur.
In anderen Lösungen findet man an dieser Stelle oftmals das umgekehrte (Black-Box-) Prinzip vor, nämlich dass der Programmierer bestimmte IDs oder andere Angaben vorgeben muss, um nach einem passenden Slave-Gerät zu suchen. Abgesehen davon, dass der Entwickler damit gezwungen wird, sich vorab die IDs und Angaben zu besorgen, ohne die er die Slaves nicht finden wird, ist ein Überblick und ein Durchsuchen des gesamten Netzes so nicht möglich. Außerdem ist regelmäßig eine große Menge an verschiedenen Funktionen bereitzustellen, da die Suchkriterien sich stark unterscheiden können. Dennoch können die vielen Funktionen doch meist nur bestimmte Fälle abdecken.
Durch die beschriebene Umkehrung dieses Prinzips im Kithara EtherCAT Master stehen dem Programmierer auf einfachere Weise wesentlich komfortablere Wege offen, um die vorhandene EtherCAT-Topologie in Variablen und Strukturen der Programmiersprache abzubilden.
Genau diese Abbildung in Variablen und Strukturen ist ja das Hauptziel der Einrichtungsphase, um mit dem eigentlichen Programmablauf beginnen zu können. Wie findet nun der Programmierer zu seinen Variablen? Um es gleich vorweg zu sagen: Er muss sich nicht ausrechnen, welches Byte-Offset seine Variable hat, er bekommt statt dessen die Adressen der Variablen frei Haus geliefert.
Dazu bedient sich der EtherCAT Master des Begriffs Dataset. Ein Dataset beschreibt eine Zusammenstellung von Slaves, PDOs und Variablen, deren Daten zyklisch zwischen dem PC-Anwenderspeicher und den EtherCAT-Geräten ausgetauscht werden. Im einfachsten Fall gibt es nur ein solches Dataset, in dem sich alle aktiven Prozessdatenobjekte befinden. Das Dataset steht für einen Speicherbereich, der alle betreffenden PDOs mit ihren Variablen abbildet. Bei der vorliegenden Lösung ist dieser Speicherbereich sogenanntes Shared Memory, das sowohl von der Anwendungs- als auch von der Kernel-Ebene aus ansprechbar ist. Der Shared-Memory-Bereich, der für ein Dataset steht, enthält Ist- und Soll-Daten und wird zyklisch wie folgt aktualisiert:
Angenommen, der Anwender hat eine Timerfunktion realisiert, in der z.B. eine Regelung stattfindet. Diese Funktion kann beispielsweise mit den Kithara-Echtzeit-Timern mit einer Frequenz von mehreren Kilohertz auf der Kernel-Ebene ablaufen. Es ist nun zu zwei Zeitpunkten ein Abgleich der Daten erforderlich: Vor der Berechnung sind die Ist-Werte von den angeschlossenen EtherCAT-Slaves einzulesen (z.B. Sensoren) – nach der Berechnung sind die neu berechneten Soll-Werte wieder an die Slaves zu schreiben (z.B. Aktoren). Diese beiden Aktionen kann der Anwender selbst steuern, da ansonsten keine Datenkonsistenz gewährleistet wäre. Es stehen zwei simple Funktionsaufrufe bereit, mit denen der ausgehende bzw. der einkommende Datenaustausch im Shared Memory veranlasst wird. Der eigentliche Datentransport findet zeitlich gesehen im Hintergrund statt, da die unterstützten Netzwerk-Controller den Transport der Ethernet-Frames selbst übernehmen.
Der Anwender bekommt also gewissermaßen die Variablen der angeschlossenen EtherCAT-Slaves (I/O-Klemmen, Sensoren, Motion Controller usw.) direkt zu Füßen gelegt und muss sich um den Transport der Daten nicht mehr kümmern. Dennoch bestimmt der Anwender den Zeitpunkt exakt. Hier ergibt sich ein weiterer Unterschied zu einigen anderen Lösungen, bei denen im Hintergund eine Art Soft-SPS zu initiieren ist, die für den Datenaustausch sorgt. Dabei können leicht Inkonsistenzen auftreten, denn die Aktualisierung der Daten erfolgt unabhängig vom Kontrollfluss des Anwenders.
Die Festlegung, welche PDOs Teil eines Datasets sein sollen, ist ebenfalls sehr einfach. Es existiert eine Funktion, mit der in der Initialisierungsphase ein beliebiges Deskriptorobjekt einem Dataset hinzugefügt werden kann. Dies kann eine Variable, ein PDO, ein Slave oder der gesamte Master-Deskriptor sein. Jede der vier Varianten hat ihren besonderen Reiz: Wird einem Dataset ein Master-Deskriptor hinzugefügt, bedeutet dies nichts anderes, als dass mit einem Aufruf alle angeschlossenen Slaves in der Standard-Konfiguration hinzugefügt werden. Das ist also die einfachste Methode. Ebenso ist es möglich, nur diejenigen Slaves einem Dataset hinzuzufügen, die tatsächlich benötigt werden. Standard-Konfiguration bedeutet hier, dass sich ein Slave über eine allgemeine Datenstruktur ansprechen lässt, die alle aktiven PDOs umfasst. Dafür werden entsprechende Header-Definitionen für die Datenstrukturen bereitgestellt, die genau der Standard-Konfiguration der jeweiligen Slave-Module entsprechen.
Als Beispiel sei das 2-Kanal-Analog-Input-Modul EL3162 von Beckhoff genannt: Es verfügt über insgesamt 3 PDOs, von denen jedoch normalerweise nur 2 aktiv sind. In den ersten beiden PDOs sind jeweils eine 16-Bit-Variable für den Analog-Wert sowie eine 8-Bit-Variable für den Status enthalten. Es existiert ein drittes PDO, das nur die 16-Bit-Variablen für die Analog-Werte der beiden Kanäle enthält. Dieses ist jedoch im Normalfall redundant und würde nur benötigt, wenn man aus Effizienzgründen auf die Status-Information verzichten wollte. Im Normalfall werden also nur die beiden ersten PDOs mit der Standard-Konfiguration unterstützt. Wenn also der entsprechende Slave-Deskriptor des besagten 2-Kanal-Analog-Input-Moduls einem Dataset hinzugefügt wird, dann werden automatisch nur die beiden Standard-PDOs zum Datenaustausch vorbereitet, während das dritte, redundante PDO nicht betrachtet wird.
Sourcecode-Beispiel 1
struct Beckhoff_EL3162
{
byte Channel1_Status;
ushort Channel1_Value;
byte Channel2_Status;
ushort Channel2_Value;
};
Diese in den meisten Fällen anwendbare Standard-Konstellation erlaubt im weiteren Verlauf ein sehr komfortables Vorgehen: Es werden für gängige EtherCAT-Slave-Module (z.B. die I/O-Klemmen der Firma Beckhoff) Header-Dateien mit fertigen Strukturdefinitionen mitgeliefert. Diese lassen sich jedoch auf einfachste Weise auch selbst erstellen. In der eingangs beschriebenen Deskriptorstruktur befindet sich nun in jedem Slave-Deskriptor ein Zeiger in den Shared Memory-Bereich, der direkt auf den Strukturtyp der Klemme gecastet werden kann.
Sourcecode-Beispiel 2
Beckhoff_EL3162* el3162 = (Beckhoff_EL3162*) ecat->slaves[3]->addr;
if (el3162->Channel1_Status == 0)
istWert = el3162->Channel1_Value;
...
Feinfühliger und nur wenig aufwändiger ist es natürlich, genau die gewünschten PDOs oder gar einzelne Variablen dem Dataset hinzuzufügen und damit exakt festzulegen, welche Daten aktualisiert werden sollen. Hier bestehen nun zwei Szenarien, die zeigen, wie flexibel der Umgang mit den Datasets ist:
Zunächst ist es möglich, mehr als ein Dataset zu definieren und genau auszuwählen, welcher Slave oder welches PDO zu einem bestimmten Dataset gehören soll. Dies erlaubt eine bessere Ausnutzung der verfügbaren Kommunikationsbandbreite. Dazu folgendes Beispiel: Angenommen, ein EtherCAT-Netzwerk enthält eine sehr große Zahl angeschlossener Slaves, dann würde die Aktualisierung aller PDOs in einem Zyklus relativ lange dauern (z.B. mehrere Millisekunden). Die meisten Slaves sind jedoch beispielhaft lediglich Temperaturfühler, die nur einmal je Sekunde gelesen werden müssten. Nur wenige Slaves sollen jedoch mit einer Frequenz von z.B. 5 Kilohertz aktualisiert werden. Hier versagen einige existierende EtherCAT-Master-Lösungen, da sie nur die Aktualisierung aller Slaves in einem einzigen Zyklus erlauben. Die Lösung ergibt sich durch das Anlegen von zwei verschiedenen Datasets: Dem einen Dataset werden alle PDOs der Temperaturfühler hinzugefügt. Dieses Dataset wird einmal je Sekunde aktualisiert. Dem anderen Dataset werden nur die wenigen Slaves hinzugefügt, die mit hoher Rate zu aktualisieren sind. Der Anwender kann nun selbst den Update-Zeitpunkt der beiden Datasets unterschiedlich bestimmen, z.B. in zwei verschieden getakteten Timer-Funktionen. Auf der Ebene der Kommunikation wird automatisch dafür gesorgt, dass die EtherCAT-Datagramme des einen Datasets mit höherer Priorität behandelt werden als die des anderen. Der spezielle Echtzeit-Ethernet-Treiber der Kithara RealTime Suite verfügt dafür über besondere Voraussetzungen, nämlich die Möglichkeit der Priorisierung der Ethernet-Frames.
Abschließend soll noch ein Ausblick auf nächste Versionen der Master-Software gegeben werden: Künftig wird es möglich sein, auch PDOs einem Dataset hinzuzufügen, die zu verschiedenen Kommunikations-Technologien gehören. So ist beabsichtigt, verschiedene Technologien (CANopen, Profinet etc.) auf gleichartige Weise zu unterstützen und dadurch eine Austauschmöglichkeit der Hardware bei im Prinzip identischer Software zu schaffen.
Fazit
Die EtherCAT-Technologie selbst ist nicht ohne Grund in aller Munde. Sie vereinfacht die Automatisierungstechnik enorm. Zeiten, in denen Anwender selbst Datenpakete zusammenfügen und die Kommunikation in die Hand nehmen mussten, gehören der Vergangenheit an. Doch neben den technischen Vorteilen von EtherCAT stellt auch die Handhabung der Master-Software eine wesentliche Vereinfachung dar.
Autor: Uwe Jesgarz, Geschäftsführer der Kithara Software GmbH
Bereits seit Jahren hält Ethernet als Kommunikationsstandard auch in der Industrie verstärkt Einzug. Dabei ist auch immer häufiger von EtherCAT die Rede. So kann man beobachten, wie vermehrt Neuentwicklungen von Automatisierungsanlagen auf der Basis von EtherCAT geplant werden. Dieser Umstieg bedeutet schnellere Kommunikation über größere Entfernungen und ist so mit einer Vielzahl von Vorteilen verbunden.
Wie jedoch steht es um die Einfachheit der Anwendung? Wie kann eine Automatisierungslösung auf der Basis von EtherCAT mindestens so einfach handhabbar sein, wie frühere Lösungen? Wie sollte eine Lösung aussehen, die nur geringen Einarbeitungsaufwand erfordert, schnellen Erfolg garantiert und so dem Anwender Zeit und Kosten einspart? Wie kann man den höchstmöglichen Grad an Effektivität gewinnen, um eine Anwendung schnell und produktiv realisieren zu können? Diesen Fragen wird im vorliegenden Artikel anhand des EtherCAT Masters eines Berliner Software-Unternehmens nachgegangen.
Der Kithara EtherCAT Master ist eine Entwicklung, die grundlegende Funktionen enthält, die in anderen Lösungen so nicht oder nur eingeschränkt zu finden sind und im Folgenden erklärt werden. Die einfache Anwendbarkeit befähigt in den meisten Fällen den Programmierer, sich sehr schnell mit der eigentlichen Realisierung seiner Applikation befassen zu können, ohne umfangreichen Einarbeitungsaufwand zu betreiben. Für spezielle Einsatzfälle ist es jedoch auch möglich, sehr fein in die Mechanismen einzugreifen. Dies erfordert dann natürlich auch einen höheren Aufwand seitens des Programmierers.
Es handelt sich um eine echtzeitfähige Lösung unter Windows. Die Echtzeitfähigkeit wird von einer speziellen Windows-Echtzeiterweiterung bereitgestellt. Diese bietet auch PC-basierte Echtzeit-Timer mit mehreren Kilohertz und verschiedene hardwarenahe Zugriffsmechanismen, einschließlich solcher zum Zugriff auf PCI-Karten oder USB-Geräte. Um die Echtzeitfähigkeit des EtherCAT Masters zu erreichen, sind zwei Voraussetzungen zu erfüllen: Zum einen muss die Netzwerkverbindung ein verzögerungsfreies Senden und eine unmittelbare Reaktion beim Empfang von Ethernet-Frames ermöglichen. Hierzu sind auf jeden Fall die langsamen Original-Treiber von Windows zu ersetzen und die Netzwerk-Hardware ist mit optimierten Treibern direkt anzusprechen. Zum anderen ist die anwenderspezifische Steuerungssoftware, die in den meisten Automatisierungsanwendungen zyklisch zeitäquidistant ausgeführt werden muss, in Echtzeit zu betreiben.
Im Folgenden wird davon ausgegangen, dass der Anwender die Steuerungssoftware selbst in C/C++ oder Delphi realisiert. Auf der Basis dieser Programmiersprachen kann der Entwickler seine Echtzeit-Routinen in seiner gewohnten Entwicklungsumgebung als Teil der Steuerungsapplikation erstellen. Dabei erfolgt die eigentliche Entwicklung der Steuerungssoftware komfortabel auf der Anwendungsebene, während diese später auf der Kernel-Ebene in Echtzeit ausgeführt wird. Auf diese Weise stehen dem Programmierer sämtliche Mechanismen als Teil einer Funktionsbibliothek zur Verfügung, zu der auch die Funktionen des EtherCAT Masters gehören.
Zunächst einmal soll die Art der Konfiguration betrachtet werden. Im einfachsten Fall ruft der Anwender eine Funktion zum Öffnen des EtherCAT Masters auf, die den Zugang zur Netzwerkkarte herstellt, die angeschlossene EtherCAT-Topologie vollständig analysiert und daraufhin eine Deskriptorstruktur zurückliefert, die alle angeschlossenen EtherCAT-Slaves (also z.B. die EtherCAT-I/O-Klemme) umfassend beschreibt. Der Anwender kann dieser Deskriptorstruktur u.a. folgende Informationen entnehmen: Oberstes Glied der Deskriptorstruktur ist der so genannte Master-Deskriptor, der u.a. angibt, wie viele EtherCAT-Slaves angeschlossen sind und einen Zugriff auf die jeweiligen Slave-Deskriptoren ermöglicht. Diese wiederum beschreiben den Slave anhand von Vendor- und Produkt-ID, Typ, Namen und einigen beschreibenden Elementen. Sie verweisen weiter auf die Deskriptoren der einzelnen Prozessdatenobjekte (PDO) und Servicedatenobjekte (SDO) und diese wiederum beschreiben jede einzelne, in ihnen enthaltene Variable mit Namen, Datentyp und Bitlänge.
Der Anwender kann also nach nur einem Funktionsaufruf zum Öffnen des EtherCAT Masters bereits vollständig das angeschlossene EtherCAT-Netz nach seinen eigenen Vorstellungen analysieren. Allein hier zeigt sich eine signifikante Vereinfachung in der Handhabung gegenüber vielen anderen Lösungen. Tests auf Vorhandensein verschiedener Slavetypen, die Lokalisierung eines bestimmten Slaves und der Vergleich mit einer vorgegebenen Topologie sind auf dieser (White-Box-) Basis ebenso einfach möglich wie beispielsweise die grafische Präsentation der Netzwerkstruktur.
In anderen Lösungen findet man an dieser Stelle oftmals das umgekehrte (Black-Box-) Prinzip vor, nämlich dass der Programmierer bestimmte IDs oder andere Angaben vorgeben muss, um nach einem passenden Slave-Gerät zu suchen. Abgesehen davon, dass der Entwickler damit gezwungen wird, sich vorab die IDs und Angaben zu besorgen, ohne die er die Slaves nicht finden wird, ist ein Überblick und ein Durchsuchen des gesamten Netzes so nicht möglich. Außerdem ist regelmäßig eine große Menge an verschiedenen Funktionen bereitzustellen, da die Suchkriterien sich stark unterscheiden können. Dennoch können die vielen Funktionen doch meist nur bestimmte Fälle abdecken.
Durch die beschriebene Umkehrung dieses Prinzips im Kithara EtherCAT Master stehen dem Programmierer auf einfachere Weise wesentlich komfortablere Wege offen, um die vorhandene EtherCAT-Topologie in Variablen und Strukturen der Programmiersprache abzubilden.
Genau diese Abbildung in Variablen und Strukturen ist ja das Hauptziel der Einrichtungsphase, um mit dem eigentlichen Programmablauf beginnen zu können. Wie findet nun der Programmierer zu seinen Variablen? Um es gleich vorweg zu sagen: Er muss sich nicht ausrechnen, welches Byte-Offset seine Variable hat, er bekommt statt dessen die Adressen der Variablen frei Haus geliefert.
Dazu bedient sich der EtherCAT Master des Begriffs Dataset. Ein Dataset beschreibt eine Zusammenstellung von Slaves, PDOs und Variablen, deren Daten zyklisch zwischen dem PC-Anwenderspeicher und den EtherCAT-Geräten ausgetauscht werden. Im einfachsten Fall gibt es nur ein solches Dataset, in dem sich alle aktiven Prozessdatenobjekte befinden. Das Dataset steht für einen Speicherbereich, der alle betreffenden PDOs mit ihren Variablen abbildet. Bei der vorliegenden Lösung ist dieser Speicherbereich sogenanntes Shared Memory, das sowohl von der Anwendungs- als auch von der Kernel-Ebene aus ansprechbar ist. Der Shared-Memory-Bereich, der für ein Dataset steht, enthält Ist- und Soll-Daten und wird zyklisch wie folgt aktualisiert:
Angenommen, der Anwender hat eine Timerfunktion realisiert, in der z.B. eine Regelung stattfindet. Diese Funktion kann beispielsweise mit den Kithara-Echtzeit-Timern mit einer Frequenz von mehreren Kilohertz auf der Kernel-Ebene ablaufen. Es ist nun zu zwei Zeitpunkten ein Abgleich der Daten erforderlich: Vor der Berechnung sind die Ist-Werte von den angeschlossenen EtherCAT-Slaves einzulesen (z.B. Sensoren) – nach der Berechnung sind die neu berechneten Soll-Werte wieder an die Slaves zu schreiben (z.B. Aktoren). Diese beiden Aktionen kann der Anwender selbst steuern, da ansonsten keine Datenkonsistenz gewährleistet wäre. Es stehen zwei simple Funktionsaufrufe bereit, mit denen der ausgehende bzw. der einkommende Datenaustausch im Shared Memory veranlasst wird. Der eigentliche Datentransport findet zeitlich gesehen im Hintergrund statt, da die unterstützten Netzwerk-Controller den Transport der Ethernet-Frames selbst übernehmen.
Der Anwender bekommt also gewissermaßen die Variablen der angeschlossenen EtherCAT-Slaves (I/O-Klemmen, Sensoren, Motion Controller usw.) direkt zu Füßen gelegt und muss sich um den Transport der Daten nicht mehr kümmern. Dennoch bestimmt der Anwender den Zeitpunkt exakt. Hier ergibt sich ein weiterer Unterschied zu einigen anderen Lösungen, bei denen im Hintergund eine Art Soft-SPS zu initiieren ist, die für den Datenaustausch sorgt. Dabei können leicht Inkonsistenzen auftreten, denn die Aktualisierung der Daten erfolgt unabhängig vom Kontrollfluss des Anwenders.
Die Festlegung, welche PDOs Teil eines Datasets sein sollen, ist ebenfalls sehr einfach. Es existiert eine Funktion, mit der in der Initialisierungsphase ein beliebiges Deskriptorobjekt einem Dataset hinzugefügt werden kann. Dies kann eine Variable, ein PDO, ein Slave oder der gesamte Master-Deskriptor sein. Jede der vier Varianten hat ihren besonderen Reiz: Wird einem Dataset ein Master-Deskriptor hinzugefügt, bedeutet dies nichts anderes, als dass mit einem Aufruf alle angeschlossenen Slaves in der Standard-Konfiguration hinzugefügt werden. Das ist also die einfachste Methode. Ebenso ist es möglich, nur diejenigen Slaves einem Dataset hinzuzufügen, die tatsächlich benötigt werden. Standard-Konfiguration bedeutet hier, dass sich ein Slave über eine allgemeine Datenstruktur ansprechen lässt, die alle aktiven PDOs umfasst. Dafür werden entsprechende Header-Definitionen für die Datenstrukturen bereitgestellt, die genau der Standard-Konfiguration der jeweiligen Slave-Module entsprechen.
Als Beispiel sei das 2-Kanal-Analog-Input-Modul EL3162 von Beckhoff genannt: Es verfügt über insgesamt 3 PDOs, von denen jedoch normalerweise nur 2 aktiv sind. In den ersten beiden PDOs sind jeweils eine 16-Bit-Variable für den Analog-Wert sowie eine 8-Bit-Variable für den Status enthalten. Es existiert ein drittes PDO, das nur die 16-Bit-Variablen für die Analog-Werte der beiden Kanäle enthält. Dieses ist jedoch im Normalfall redundant und würde nur benötigt, wenn man aus Effizienzgründen auf die Status-Information verzichten wollte. Im Normalfall werden also nur die beiden ersten PDOs mit der Standard-Konfiguration unterstützt. Wenn also der entsprechende Slave-Deskriptor des besagten 2-Kanal-Analog-Input-Moduls einem Dataset hinzugefügt wird, dann werden automatisch nur die beiden Standard-PDOs zum Datenaustausch vorbereitet, während das dritte, redundante PDO nicht betrachtet wird.
Sourcecode-Beispiel 1
struct Beckhoff_EL3162
{
byte Channel1_Status;
ushort Channel1_Value;
byte Channel2_Status;
ushort Channel2_Value;
};
Diese in den meisten Fällen anwendbare Standard-Konstellation erlaubt im weiteren Verlauf ein sehr komfortables Vorgehen: Es werden für gängige EtherCAT-Slave-Module (z.B. die I/O-Klemmen der Firma Beckhoff) Header-Dateien mit fertigen Strukturdefinitionen mitgeliefert. Diese lassen sich jedoch auf einfachste Weise auch selbst erstellen. In der eingangs beschriebenen Deskriptorstruktur befindet sich nun in jedem Slave-Deskriptor ein Zeiger in den Shared Memory-Bereich, der direkt auf den Strukturtyp der Klemme gecastet werden kann.
Sourcecode-Beispiel 2
Beckhoff_EL3162* el3162 = (Beckhoff_EL3162*) ecat->slaves[3]->addr;
if (el3162->Channel1_Status == 0)
istWert = el3162->Channel1_Value;
...
Feinfühliger und nur wenig aufwändiger ist es natürlich, genau die gewünschten PDOs oder gar einzelne Variablen dem Dataset hinzuzufügen und damit exakt festzulegen, welche Daten aktualisiert werden sollen. Hier bestehen nun zwei Szenarien, die zeigen, wie flexibel der Umgang mit den Datasets ist:
Zunächst ist es möglich, mehr als ein Dataset zu definieren und genau auszuwählen, welcher Slave oder welches PDO zu einem bestimmten Dataset gehören soll. Dies erlaubt eine bessere Ausnutzung der verfügbaren Kommunikationsbandbreite. Dazu folgendes Beispiel: Angenommen, ein EtherCAT-Netzwerk enthält eine sehr große Zahl angeschlossener Slaves, dann würde die Aktualisierung aller PDOs in einem Zyklus relativ lange dauern (z.B. mehrere Millisekunden). Die meisten Slaves sind jedoch beispielhaft lediglich Temperaturfühler, die nur einmal je Sekunde gelesen werden müssten. Nur wenige Slaves sollen jedoch mit einer Frequenz von z.B. 5 Kilohertz aktualisiert werden. Hier versagen einige existierende EtherCAT-Master-Lösungen, da sie nur die Aktualisierung aller Slaves in einem einzigen Zyklus erlauben. Die Lösung ergibt sich durch das Anlegen von zwei verschiedenen Datasets: Dem einen Dataset werden alle PDOs der Temperaturfühler hinzugefügt. Dieses Dataset wird einmal je Sekunde aktualisiert. Dem anderen Dataset werden nur die wenigen Slaves hinzugefügt, die mit hoher Rate zu aktualisieren sind. Der Anwender kann nun selbst den Update-Zeitpunkt der beiden Datasets unterschiedlich bestimmen, z.B. in zwei verschieden getakteten Timer-Funktionen. Auf der Ebene der Kommunikation wird automatisch dafür gesorgt, dass die EtherCAT-Datagramme des einen Datasets mit höherer Priorität behandelt werden als die des anderen. Der spezielle Echtzeit-Ethernet-Treiber der Kithara RealTime Suite verfügt dafür über besondere Voraussetzungen, nämlich die Möglichkeit der Priorisierung der Ethernet-Frames.
Abschließend soll noch ein Ausblick auf nächste Versionen der Master-Software gegeben werden: Künftig wird es möglich sein, auch PDOs einem Dataset hinzuzufügen, die zu verschiedenen Kommunikations-Technologien gehören. So ist beabsichtigt, verschiedene Technologien (CANopen, Profinet etc.) auf gleichartige Weise zu unterstützen und dadurch eine Austauschmöglichkeit der Hardware bei im Prinzip identischer Software zu schaffen.
Fazit
Die EtherCAT-Technologie selbst ist nicht ohne Grund in aller Munde. Sie vereinfacht die Automatisierungstechnik enorm. Zeiten, in denen Anwender selbst Datenpakete zusammenfügen und die Kommunikation in die Hand nehmen mussten, gehören der Vergangenheit an. Doch neben den technischen Vorteilen von EtherCAT stellt auch die Handhabung der Master-Software eine wesentliche Vereinfachung dar.
Autor: Uwe Jesgarz, Geschäftsführer der Kithara Software GmbH
