Prozessdatenobjekte (PDO)

Bei vielen Feldbussystemen wird ständig das gesamte Prozessabbild übertragen - meist mehr oder weniger zyklisch. CANopen ist nicht auf dieses Kommunikationsprinzip beschränkt, da bei CANopen die Prozessdaten nach dem Produzenten/Konsumenten-Modell übertragen werden. Dabei sendet ein Teilnehmer seine Prozessdaten von sich aus (Produzent), alle anderen Teilnehmer hören mit und entscheiden anhand eines CAN-Identifier, ob sie sich für dieses Telegramm interessieren und verarbeiten es entsprechend (Konsument).

Bei CANopen werden die Prozessdaten in Segmente zu maximal 8 Byte aufgeteilt. Diese Segmente heißen Prozessdatenobjekte (PDOs). Die Prozessdatenobjekte (PDOs) entsprechen jeweils einem CAN-Telegramm und werden durch einen spezifischen CAN-Identifier zugeordnet und in ihrer Priorität bestimmt.

Die Prozessdatenobjekte (PDOs) werden in Empfangs-PDOs (RxPDOs) und Sende-PDOs (TxPDOs) unterteilt, wobei die Bezeichnung jeweils aus Sicht der Teilnehmer erfolgt. Ein Teilnehmer sendet seine Eingangsdaten mit TxPDOs, und empfängt die Ausgangsdaten in den RxPDOs.
Diese Bezeichnung wird in TwinCAT beibehalten.

Kommunikationsparameter

Die Prozessdatenobjekte (PDOs) können je nach Anforderung mit unterschiedlichen Kommunikationsparametern versehen werden. Wie alle CANopen-Parameter stehen auch diese im Objektverzeichnis des Gerätes. Auf die Kommunikationsparameter kann über Servicedatenobjekte (SDOs) zugegriffen werden.

Die Parameter für die Empfangs-PDOs stehen bei Index 0x1400 (RxPDO1) bis Index 0x15FF (RxPDO512), damit können bis zu 512 RxPDOs vorhanden sein. Entsprechend finden sich die Einträge für die Sende-PDOs bei Index 0x1800 (TxPDO1) bis Index 0x19FF (TxPDO512).

Für jedes vorhandene Prozessdatenobjekt (PDO) ist ein zugehöriges Kommunikationsparameter-Objekt vorhanden. TwinCAT ordnet die eingestellten Parameter automatisch den jeweiligen Objektverzeichniseinträgen zu. Im Folgenden werden diese Einträge samt ihrer Bedeutung für das Kommunikationsverhalten der Prozessdaten erläutert.

CAN-Identifier

Der wichtigste Kommunikationsparameter für Prozessdatenobjekte (PDOs) ist der CAN-Identifier (auch Communication Object Identifier, COB-ID genannt). Der CAN-Identifier dient zur Identifizierung der CAN-Telegramme und bestimmt deren Priorität beim Buszugriff. Für jedes CAN-Telegramm darf es nur einen Sender (Produzenten) geben, da CAN jedoch alle Nachrichten im Broadcast-Verfahren sendet kann ein Telegramm wie beschrieben von beliebig vielen Teilnehmern empfangen werden (Konsumenten). Ein Teilnehmer kann also seine Eingangsinformation mehreren Teilnehmern gleichzeitig zur Verfügung stellen - auch ohne Weiterleitung durch einen logischen Master.

Der CAN-Identifier steht in Subindex 1 des Kommunikationsparametersatzes. Er ist als 32-Bit Wert kodiert, wobei die niederwertigsten 11 Bits (Bit 0...10) den eigentlichen CAN-Identifier enthalten. Die Datenbreite des Objektes von 32 Bit erlaubt auch den Eintrag von 29 Bit CAN-Identifiern. Der Einsatz der 29Bit-Variante bleibt auf Sonderanwendungen beschränkt - und wird daher auch von den Beckhoff CANopen-Geräten nicht unterstützt wird. Über das höchstwertige Bit (Bit 31) lässt sich das Prozessdatenobjekt aktivieren bzw. abschalten.

PDO-Linking

Standardmäßig kommunizieren alle Teilnehmer (Slaves) mit einer Zentrale (Master). Kein Slave hört wegen seinen Voreinstellungen auf die Prozessdatenobjekte (PDOs) und damit auf die CAN-Identifier eines anderen Slaves.

Standardkommunikation zwischen mehreren Slaves und einem Master:

Sollen die Prozessdatenobjekte (SDOs) direkt zwischen den Teilnehmern ohne Master ausgetauscht werden, so müssen die CAN-Identifier entsprechend angepasst werden. Die TxPDO-Identifier des Produzenten müssen mit dem RxPDO-Identifier des Konsumenten übereinstimmen. Dieses Verfahren nennt man PDO-Linking. Es ermöglicht beispielsweise den einfachen Aufbau von elektronischen Getrieben, bei denen mehrere Slave-Achsen gleichzeitig auf den Ist-Wert im TxPDO der Master-Achse hören.

Kommunikation ohne Master mit PDO-Linking:

PDO-Übertragungsarten

CANopen bietet folgende Möglichkeiten die Prozessdatenobjekte (PDOs) zu übertragen:

• Ereignisgesteuert
• Durch Polling
• Synchronisiert
  
  

• Ereignisgesteuert:
  Ändert sich ein Eingangswert, überträgt ein Teilnehmer sofort seine Prozessdatenobjekte (PDOs). Dadurch wird die Übertragungsbandbreite optimal ausgenutzt, da nur die Änderung des Prozessabbildes übertragen wird. Gleichzeitig ist die Reaktionszeit kurz, die Teilnehmer warten bei einer Änderung der Eingangswerte nicht auf die Abfrage durch einen Master.
  
  Ab CANopen Version 4 kann die ereignisgesteuerte Kommunikationsart mit einem zyklischen Update kombiniert werden. Dabei werden die Prozessdatenobjekte (in diesem Fall sind es die TxPDOs) dann übertragen, wenn eine zuvor eingestellte Zeit (Event Timer) abgelaufen ist. Ändert sich ein Eingangswert innerhalb der eingestellten Zeit, wird die Zeit (Event Timer) zurückgesetzt.
  
  Bei RxPDOs wird die eingestellte Zeit (Event Timer) dazu benutzt das Eintreffen der ereignisgesteuerten Prozessdatenobjekte (PDOs) zu überwachen. Ein Teilnehmer geht in den Fehlerzustand, wenn innerhalb der eingestellten Zeit keine Prozessdatenobjekte (PDOs) eintreffen.
  
• Gepollt:
  Die Prozessdatenobjekte (PDOs) werden durch Anforderungstelegramme (Remote Frames) gepolt. Auf diese Weise werden die Prozessdatenobjekte (PDOs) auch ohne deren Änderung übertragen, beispielsweise bei einem zur Laufzeit ins Netz aufgenommenen Monitor oder Diagnosegerät.
  
  Bausteine mit integrierter kompletter Nachrichtenfilterung (FullCAN) beantworten ein Anforderungstelegramm in der Regel direkt und versenden sofort die im entsprechenden Sendebuffer stehenden Daten. Dort muss die Applikation dafür Sorge tragen, dass die Daten ständig aktualisiert werden. CAN-Controller mit einfacher Nachrichtenfilterung (BasicCAN) reichen die Anforderung dagegen an die Applikation weiter, die nun das Telegramm mit den aktuellen Daten zusammenstellen kann. Das dauert länger, dafür sind die Daten aktuell. Beckhoff verwendet CAN Controller nach dem Basic CAN Prinzip.
  
  Da dieses Geräteverhalten für den Anwender meist nicht transparent ist und zudem noch CAN-Controller in Verwendung sind, die Remote Frames überhaupt nicht unterstützen, wird die gepollte Kommunikationsart nur bedingt für den laufenden Betrieb empfohlen.
  
• Synchronisiert
  Nicht nur bei Antriebsanwendungen ist es sinnvoll, das Ermitteln der Eingangsinformation sowie das Setzen der Ausgänge zu synchronisieren. CANopen stellt hierzu das SYNC-Objekt zur Verfügung, ein CAN-Telegramm hoher Priorität ohne Nutzdaten, dessen Empfang von den synchronisierten Teilnehmern als Trigger für das Lesen der Eingänge bzw. für das Setzen der Ausgänge verwendet wird.

PDO-Übertragungsarten: Parametrierung

Die PDO-Übertragungsart (Transmission Type) legt fest, wie die Übertragung der Prozessdatenobjekte (PDOs) ausgelöst wird bzw. wie empfangene Prozessdatenobjekte (PDOs) behandelt werden:

Die Übertragungsart wird für RxPDOs in den Objekten 0x1400ff, Subindex 2, und für TxPDOs in den Objekten 0x1800ff, Subindex 2 parametriert. In TwinCAT wird die PDO-Übertragungsart auf der Registerkarte PDO unter Transmission Type eingestellt (siehe: Registerkarte PDO).

• Azyklisch Synchron:
  PDOs der Übertragungsart 0 arbeiten synchron, aber nicht zyklisch. Ein RxPDO wird erst nach dem nächsten SYNC-Telegramm ausgewertet. Damit lassen sich beispielsweise Achsgruppen nacheinander mit neuen Zielpositionen versehen, die alle beim nächsten SYNC gültig werden - ohne dass ständig Stützstellen ausgegeben werden müssen.
  Im Vergleich dazu ermittelt ein TxPDO seine Eingangsdaten nach einem SYNC-Telegramm (synchrones Prozessabbild) und sendet seine Eingangsdaten dann weiter, wenn sich die Eingangsdaten geändert haben.
  Die Übertragungsart 0 kombiniert also den Sendegrund „Synchronisiert“ mit dem Sendegrund „Ereignisgesteuert“.
  
• Zyklisch Synchron:
  Bei Übertragungsart 1-240 wird das PDO zyklisch nach jedem "n-ten" SYNC gesendet (n=1...240). Auf diese Weise kann beispielsweise ein schneller Zyklus für digitale Eingänge parametriert werden (n=1), während die Daten der Analogeingänge in einem langsameren Zyklus übertragen werden (z.B. n=10). RxPDOs unterscheiden in der Regel nicht zwischen den Übertragungsarten 0...240. Ein empfangenes PDO wird beim nächsten SYNC-Telegramm gültig gesetzt. Die Zykluszeit (SYNC-Rate) kann überwacht werden (Objekt 0x1006), das Gerät reagiert bei SYNC-Ausfall dann entsprechend der Definition des Geräteprofils und schaltet z.B. seine Ausgänge in den Fehlerzustand.
  
  Das SYNC-Telegramm ist mit der verknüpften Task gekoppelt, sodass zu jedem Taskbeginn neue Eingangsdaten zur Verfügung stehen. Bleibt ein synchrones PDO aus, wird es erkannt und an die Applikation gemeldet.
  
• Asynchron:
  Die Übertragungsarten 254 + 255 sind asynchron oder ereignisgesteuert. Bei Übertragungsart 254 ist das Ereignis herstellerspezifisch, bei 255 im Geräteprofil definiert. Im einfachsten Fall ist das Ereignis die Veränderung eines Eingangswertes - es wird also jede Werteänderung übertragen. Die Asynchrone Übertragungsart kann mit dem Event Timer gekoppelt werden und liefert so auch dann Eingangsdaten, wenn aktuell kein Ereignis aufgetreten ist. Läuft die eingestellte Zeit ab, wird das als zusätzlich eingetretenes Ereignis gewertet und die Eingangsdaten werden gesendet.

PDO Mapping

Unter PDO-Mapping versteht man die Abbildung der Applikationsobjekte (Echtzeitdaten) aus dem Objektverzeichnis in die Prozessdatenobjekte. Die CANopen-Geräteprofile sehen für jeden Gerätetyp ein Default Mapping vor, das für die meisten Anwendungen passend ist. So bildet das Default Mapping für digitale E/A einfach die Ein- bzw. Ausgänge ihrer physikalischen Reihenfolge gemäß in die Sende- bzw. Empfangs-Prozessdatenobjekte ab.

Die Default-PDOs für Antriebe enthalten jeweils 2 Byte Steuer- bzw. Statuswort und Soll- bzw. Istwert für die betreffende Achse. 

Das aktuelle Mapping kann über entsprechende Einträge im Objektverzeichnis, die sogenannten Mapping-Tabellen, gelesen werden. An erster Stelle der Mapping Tabelle (Subindex 0) steht die Anzahl der gemappten Objekte, die im Anschluss aufgelistet sind. Die Tabellen befinden sich im Objektverzeichnis bei Index 0x1600 ff. für die RxPDOs bzw. 0x1A00ff für die TxPDOs.

Digitale und analoge Ein-/Ausgabebaugruppen: E/A-Anzahl auslesen

Die aktuelle Anzahl der digitalen und analogen Ein-/Ausgänge lässt sich durch Auslesen der entsprechenden Applikationsobjekte im Objektverzeichnis ermitteln bzw. verifizieren:

Variables Mapping

In der Regel genügt die Default-Belegung der Prozessdatenobjekte (Default Mapping) bereits den Anforderungen. Für spezielle Anwendungsfälle kann die Belegung jedoch verändert werden: So unterstützen beispielsweise die Beckhoff CANopen Buskoppler das variable Mapping, bei dem die Applikationsobjekte (Ein- und Ausgangsdaten) frei den PDOs zugeordnet werden können. Hierzu müssen die Mapping-Tabellen konfiguriert werden: Ab CANopen Version 4 ist nur noch die folgende Vorgehensweise zulässig, die genau eingehalten werden muss:

1. Zunächst PDO löschen (0x1400ff, bzw. 0x1800ff, Subindex 1, Bit 31 auf "1" setzen) 
2. Subindex 0 im Mapping Parameter (0x1600ff bzw. 0x1A00ff) auf "0" setzen 
3. Mapping Einträge (0x1600ff bzw. 0x1A00ff, SI 1..8) verändern 
4. Subindex 0 im Mapping Parameter auf gültigen Wert setzen. Das Gerät überprüft dann die Einträge auf Konsistenz.
5. PDO anlegen durch Eintragen d. Identifiers (0x1400ff bzw. 0x1800ff Subindex 1).

Dummy-Mapping

Ein weiteres Feature von CANopen ist das Mappen von Platzhaltern (Dummy-Einträgen). Als Platzhalter dienen die im Objektverzeichnis hinterlegten Datentyp-Einträge, die ja selbst nicht mit Daten versehen sind. Sind solche Einträge in der Mapping-Tabelle enthalten, so werden die entsprechenden Daten vom Gerät nicht ausgewertet. Auf diese Art können beispielsweise mehrere Antriebe über ein einziges CAN-Telegramm mit neuen Sollwerten versorgt werden oder Ausgänge auf mehreren Knoten auch im ereignisgesteuerten Modus gleichzeitig gesetzt werden.