Der Grund für die steigende Verbreitung von EtherCAT in der Automatisierung ist sicher bei den vielfältigen Vorteilen dieser Technik zu suchen. Aber wie einfach sind derartige Anwendungen umsetzbar? Wie erreicht man einen geringen Einarbeitungsaufwand und damit Zeit- und Kosteneinsparungen? Diesen Fragen wird hier am Beispiel des EtherCAT-Masters der Berliner Firma Kithara Software nachgegangen.
Beim EtherCAT-Master von Kithara handelt es sich um eine Windows-Lösung, die im Rahmen der seit mehreren Jahren verfügbaren Windows-Echtzeiterweiterung Kithara Realtime Suite bereitgestellt wird. 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 Kithara EtherCAT-Masters zu erreichen, ermöglicht das System zum einen bei der Netzwerkverbindung ein verzögerungsfreies Senden sowie eine unmittelbare Reaktion beim Empfang von Ethernet-Frames. Hierzu wird die Netzwerk-Hardware mit optimierten Treibern direkt angesprochen. Zum anderen lässt sich die anwenderspezifische Steuerungssoftware, die in den meisten Automatisierungsanwendungen zyklisch zeitäquidistant ausgeführt werden muss, in Echtzeit betreiben. Die Echtzeit-Steuerungssoftware kann der Anwender in seiner gewohnten Entwicklungsumgebung in C/C++ oder Delphi als Teil der Steuerungsapplikation erstellen. Dabei erfolgt die eigentliche Entwicklung komfortabel auf der Anwendungsebene, während die zeitkritischen Teile der Applikation später auf der Kernel-Ebene in Echtzeit ausgeführt werden. 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 muss eine Funktion zum Öffnen des EtherCAT-Masters aufgerufen werden. Diese stellt den Zugang zur Netzwerkkarte her, analysiert die angeschlossene EtherCAT-Topologie vollständig und liefert daraufhin eine Deskriptorstruktur zurück, die alle angeschlossenen EtherCAT-Slaves (also beispielsweise die EtherCAT-I/O-Klemmen) umfassend beschreibt. Oberstes Glied der Deskriptorstruktur ist der so genannte Master-Deskriptor, der unter anderem angibt, wie viele EtherCAT-Slaves angeschlossen sind und der auch einen Zugriff auf die jeweiligen Slave-Deskriptoren ermöglicht. Diese wiederum beschreiben den Slave anhand von Vendor- und Produkt-ID, Typ, Namen und einigen weiteren Elementen. Sie verweisen zudem auf die Deskriptoren der einzelnen Prozessdatenobjekte (PDO) und Servicedatenobjekte (SDO). Diese wiederum beschreiben jede einzelne, in ihnen enthaltene Variable mit Namen, Datentyp und Bitlänge.
Komfortable Abbildung der Topologie
Nach diesem ersten Schritt kann das angeschlossene EtherCAT-Netz vollständig analysiert werden. Dies vereinfacht die Handhabung und erlaubt beispielsweise die Lokalisierung eines bestimmten Slaves oder den Vergleich mit einer vorgegebenen Topologie. Somit muss der Programmierer nicht – wie sonst oft üblich – bestimmte IDs oder andere Angaben vorgeben, um nach einem passenden Slave-Gerät zu suchen. Auch wäre so ein Gesamtüberblick über das Netz nicht möglich. Das beschriebene Prinzip erlaubt dem Programmierer die einfache und komfortable Abbildung der vorhandenen EtherCAT-Topologie in Variablen und Strukturen seiner Programmiersprache. Dabei ist es nicht nötig, auszurechnen, welches Byte-Offset jede einzelne Variable hat. Stattdessen werden die Adressen der Variablen „frei Haus“ geliefert.
Dazu stellt der EtherCAT-Master so genannte Datasets bereit. Dies ist 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 ein so genanntes 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 beispielsweise eine Regelung stattfindet. Diese Funktion kann 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 angeschlossener EtherCAT-Slaves einzulesen (beispielsweise Sensoren), nach der Berechnung sind die neu berechneten Soll-Werte wieder an die Slaves zu schreiben (beispielsweise Aktoren). Diese beiden Aktionen steuert der Anwender selbst und gewährleistet so die Datenkonsistenz. Es stehen zwei simple Funktionsaufrufe bereit, mit denen der ausgehende beziehungsweise der einkommende Datenaustausch im Shared Memory veranlasst wird. Den eigentlichen Datentransport der Ethernet-Frames übernehmen die unterstützten Netzwerk-Controller selbst. Der Anwender bekommt also gewissermaßen die Variablen der angeschlossenen EtherCAT-Slaves (beispielsweise I/O-Klemmen, Sensoren oder Motion Controller) direkt „zu Füßen gelegt“ und muss sich um den Transport der Daten nicht mehr kümmern. Zur Festlegung, welche PDOs Teil eines Datasets sein sollen, existiert eine Funktion, mit der in der Initialisierungsphase ein beliebiges Deskriptorobjekt einem Dataset hinzugefügt werden soll. Dies kann eine Variable, ein PDO, ein Slave oder der gesamte Master-Deskriptor sein. Es lassen sich damit beispielsweise alle oder nur bestimmte Slaves in der Standard-Konfiguration hinzufügen oder die gewünschten PDOs gezielt auswählen. Standard-Konfiguration bedeutet hier, dass sich ein Slave über eine allgemeine Datenstruktur ansprechen lässt, die alle aktiven PDOs umfasst.
Einfache Handhabung
Als Beispiel sei das 2-Kanal-Analog-Input-Modul EL3162 von Beckhoff genannt: Es verfügt über drei PDOs, von denen jedoch normalerweise nur zwei 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. Wenn der entsprechende Slave-Deskriptor des 2-Kanal-Analog-Input-Moduls einem Dataset hinzugefügt wird, werden automatisch nur die beiden Standard-PDOs zum Datenaustausch vorbereitet, während das dritte PDO nicht betrachtet wird.
Diese in den meisten Fällen anwendbare Standard-Konstellation erlaubt ein komfortables Vorgehen: Mit dem Kithara EtherCAT-Master werden für gängige EtherCAT-Slave-Module Header-Dateien mit fertigen Strukturdefinitionen mitgeliefert. In der eingangs beschriebenen Deskriptorstruktur befindet sich in jedem Slave-Deskriptor ein Zeiger in den Shared Memory-Bereich, der direkt auf den Strukturtyp des Slave-Moduls konvertiert werden kann. Es ist auch möglich, mehr als ein Dataset zu definieren und auszuwählen, welcher Slave oder welches PDO zu einem bestimmten Dataset gehören soll. Dies erlaubt eine bessere Ausnutzung der Kommunikationsbandbreite und gestattet dem Anwender außerdem, den Update-Zeitpunkt der beiden Datasets unterschiedlich selbst zu bestimmen.
• more@click-Code: ADK89071
