Ein typisches Powerlink/CANopen-Gateway lässt sich durch Verwendung einer Standard-CPU mit integriertem CANController und MAC realisieren. Um akzeptable Latenz- und Reaktionszeiten zu erreichen, ist eine 32-Bit-CPU mit durchschnittlicher Leistung zu wählen. Grundsätzlich müssen ein Powerlink- und ein CANopen-Stack implementiert sein. Zwischen den Stacks ist eine „System Control Task“ für den Fernzugriff via SDO und die Weiterleitung von NMT-Meldungen und Fehlerinformationen zuständig.
Der Austausch von Prozessdaten läuft über das Prozessabbild, das auf einen gemeinsamen Speicher beider Stacks zurückgreift. Auf Grundlage der Netzwerk-Variablen, wie sie in den Spezifikationen CiA302 und CiA405 definiert sind, können die RxPDOs (eingehenden Prozessdaten) flexibel auf die TxPDOs (ausgehenden Prozessdaten) abgebildet werden. Innerhalb des Speicherbereiches A000h bis A8FFh verweist jeder Objekteintrag mit festgelegtem Index mittels Datentyp-Definition und Address-Offset auf einen bestimmten Speicherbereich im Input- beziehungsweise Output-Prozessabbild.
Um mit einem Gateway SDO-Zugangsdienste nutzen zu können, ist eine Erweiterung der bestehenden SDO-Protokolle nötig. Für CANopen wurden mit dem „SDO Network Indication Protocol“ die entsprechenden Erweiterungen bereits mit der Spezifikation CiA400 eingeführt. Was die Erweiterung der SDO-Protokolle oder SDO-Dienste seitens Powerlink betrifft, gilt es, zwei Szenarien zu unterscheiden:
1.) Das Gerät, auf das via SDO zugegriffen werden soll, befindet sich in einem Netzwerk, das ohne den Umweg über ein CANopen-Netzwerk erreicht werden kann.
2.) Das Gerät befindet sich in einem Netzwerk, das nur über ein CANopen-Netzwerk zu erreichen ist.
Im ersten Fall antwortet das Gateway auf die CANopen-eigene „SDO-Network-Indication“-Anfrage und wartet auf die darauf folgende SDO-Zugangsanfrage. Diese Anfrage wird dann an den neuen „SDO Remote Read by Index“ von Powerlink oder an den Dienst „SDO Remote Write by Index“ weitergeleitet. Beide Dienste nutzen die Parameter „net_id“ und „node_id“, um auf das entsprechende Gerät zu verweisen.
Im Fall 2 ist das „SDO Network Indication Protocol“ über das Powerlink-Netzwerk zu routen. Hierzu wurde der neue Powerlink-Dienst „SDO Network Indication“ eingeführt. Dieser Dienst arbeitet genauso wie der CANopen-Dienst, was bedeutet, dass das Gateway die Powerlink-SDO-Network-Indication-Anfrage zum nächsten Powerlink/CANopen-Gateway überträgt und auf die Antwort wartet. Nach Erhalt der Antwort übermittelt es die SDO-Network-Indication-Antwort an sein CANopen-Interface.
Für beide Fälle gilt: Das Gateway benötigt eine Übertragungsstabelle, die Informationen darüber enthält, ob ein Netzwerk direkt – also ausschließlich über Powerlink – zugänglich ist, oder ob noch CANopen-Netzwerke dazwischen liegen. Diese Übertragungsstabelle lässt sich über Einträge in das Objektverzeichnis konfigurieren.
Ein CANopen-Master oder ein Managing-Node bei Powerlink kann aufgefordert werden, NMT-Dienste, wie in CiA302 definiert, für CANopen unter Verwendung von Objekt 1F82h zu senden; für Powerlink unter Verwendung von Objekt 1F9Fh.
Fehlermeldungen, deren Übertragung bei CANopen in Form einer Ereignismeldung (emergency message) und bei Powerlink über den Fehlersignal-Mechanismus (error signaling mechanism) erfolgt, lassen sich vom Gateway zu einem anderen Netzwerk mittels eines dedizierten Fehlercodes weiterleiten. Dieser Fehlercode zeigt an, dass der Fehler in einem anderen Netzwerk aufgetreten ist. In einem zusätzlichen Informationsabschnitt der Fehlermeldung ist die Fehlerquelle durch Netzwerk-ID, Knoten-ID und dem originalen Fehler-Code beschreibbar. Zusätzlich Objekteinträge im Gateway ermöglichen eine Konfiguration dahingehend, welche Fehler an andere Netzwerke weitergeleitet werden sollen.
Zusammenfassend lässt sich festhalten: Powerlink/CANopen-Gateways ermöglichen Systemdesigns, bei denen je nach Anwendung die angemessene Kommunikationslösung entweder durch Powerlinkoder durch CANopen-basierte Subsysteme umgesetzbar sind. Außerdem erlauben Router und eine große Vielfalt von gemischten Netzwerkarchitekturen, mit denen sich neue Anwendungsgebiete erschließen lassen. gh
![]() | Christian Schlegel ist technischer Geschäftsführer der Firma Ixxat Automation. |