Spezifikation erweitert

Die Hersteller- und Anwendervereinigung CAN in Automation hat ihre Spezifikationen überarbeitet. Neu ist zum einen ein CANopen-Gerätemodell zur Beschreibung logischer und virtueller Geräte, zum anderen wurden Regeln für die Beschreibung von CANopen-Geräten in XML definiert.

Die Hersteller- und Anwendervereinigung CAN in Automation hat ihre Spezifikationen überarbeitet. Neu ist zum einen ein CANopen-Gerätemodell zur Beschreibung logischer und virtueller Geräte, zum anderen wurden Regeln für die Beschreibung von CANopen-Geräten in XML definiert.

Entsprechend der neuen Version 4.1 der CiA 301 „Application layer and communication profile“ kann ein Feldgerät mehrere, vollwertige CANopen-„Geräte“ beherbergen, wobei jedes CANopen- Gerät seine eigene CANopen-Schnittstelle besitzt. Ein einzelnes CANopen-Gerät kann wiederum über bis zu acht logische Geräte verfügen. Dies bedeutet, dass sich innerhalb eines einzelnen CANopen- Geräts bis zu acht CANopen Geräte- beziehungsweise Applikationsprofile implementieren lassen. Somit könnte beispielsweise ein elektrischer Antrieb mit CANopen- Schnittstelle im ersten logischen Gerät das Antriebsprofil CiA 402 unterstützen und darüber hinaus das Profil CiA 401 für Ein-/Ausgabemodule zum Steuern weiterer Funktionen.

Gemäß dem Gerätemodell in CiA 301 kann sich ein logisches Gerät aus einer beliebigen Anzahl von Funktionsbausteinen (virtuelle Geräte) zusammensetzen. Das Konzept der virtuellen Geräte ist insbesondere zum Beschreiben der CANopen-Applikationsprofile nötigt. Beim Erstellen von Applikationsprofilen wird ein Steuerungssystem in seine kleinsten Funktionsbausteine zerlegt. Für jeden dieser Funktionsbausteine ist festgelegt, welche Daten für die jeweilige Funktion erforderlich sind und welche Informationen wieder an das System zurückzuliefern sind. Somit ergeben sich automatisch die Objektverzeichnis- Einträge, die für den jeweiligen Funktionsbaustein nötig sind. Ein Geräte-Entwickler hat dann die Möglichkeit zu evaluieren, welche Funktionsbausteine er in seinem Gerät unterstützen möchte. Das Objektverzeichnis setzt sich gemäß der unterstützten Funktionen zusammen und der Hersteller kann ein Gerät mit „Plug-and-play“- Verhalten innerhalb von CANopen-Netzwerken auf den Markt bringen, die dem entsprechenden CANopen-Applikationsprofil folgen.

Der Zählwert in der Sync-Nachricht

Die CANopen Sync-Nachricht ist ein seit langem genutztes CANopen- Kommunikationsobjekt und dient der Erzeugung eines synchronen Netzwerkverhaltens. Bis dato war diese gekennzeichnet durch den vordefinierten CAN-Identifier 80h und 0 Byte Daten. Erfordert die Applikation jedoch mehrere (virtuelle) Sync-Nachrichten, stieß der Systemintegrator bislang schnell an Grenzen. Daher wurde in der neuen CANopen-Version die bestehende Sync-Nachricht um einen optionalen 1-Byte-Zählwert erweitert. Pro gesendete Sync- Nachricht erhöht sich der Zähler um den Wert 1. Dies ermöglicht dem Systemintegrator, ein an das Sync-Signal gekoppeltes Geräteverhalten zwischen verschiedenen Netzwerk-Teilnehmern besser zu koordinieren. Gleiches gilt für PDOs (Prozessdaten-Objekte), die an die Sync-Nachricht gekoppelt sind. Mittels des neuen Sub-index 06h (Sync Start Value) in den PDO-Kommunikationsparametern lässt sich zudem justieren, bei welchem Sync-Zählwert das entsprechende PDO zum ersten Mal gesendet werden soll. Das weitere Senden des PDOs erfolgt dann wie bisher in strenger Abhängigkeit vom Eintrag in Sub-index 02h (Transmission Type). Der maximale Sync-Zählwert ist in dem neu geschaffenen Objekt 1019h (Synchronous Counter Overflow Value) einstellbar.

Eine andere Erweiterung der CANopen-Spezifikation betrifft das Erkennen dynamisch eingerichteter SDO-Verbindungen (SDO – Servicedaten-Objekt). Unter dem Begriff des CANopen-SDO-Managers wird unter anderem die Funktionalität eines Gerätes verstanden, SDO-Verbindungen zwischen zwei beliebigen Netzwerk-Teilnehmern aufzubauen. Diese dynamischen Verbindungen werden nur temporär genutzt und anschließend wieder abgebaut. Daher erfolgt das Schreiben der Parametersätze von dynamischen SDO-Verbindungen nicht in den nichtflüchtigen Speicher, da diese im Falle eines Reset-Befehls verloren gehen würden. Um die im Betrieb dynamisch erstellten SDO-Verbindungen von jenen zu unterscheiden, die beispielsweise der Systemintegrator bei Inbetriebnahme statisch eingerichtet hat und die auch nach einem Reset-Befehl erhalten bleiben, führt die neue Version der CiA 301 das „Dyn-Bit“ ein. Dieses spezielle Bit im Kommunikationsobjekt-Identifier (COB-ID) des jeweiligen SDO-Parametersatzes kann zukünftig als Unterscheidungsmerkmal zwischen voreingestellten und dynamisch erzeugten SDO-Verbindungen dienen.