Optimierung der PDO-Kommunikation in CANopen-Netzwerken

Anbieter zum Thema

TURCK GmbH

FAULHABER Antriebssysteme

PEAK-System Technik GmbH

CAN in Automation (CiA) GmbH

Synchrone PDO-Übertragung

Eine gleichmäßige Verteilung der Buslast ist eine der wichtigsten Aufgaben bei der Systemauslegung. So kann man die maximale Buslast und die daraus resultierende maximale Übertragungsgeschwindigkeit möglichst gering halten. In CANopen gibt es dazu die synchrone Übertragung von PDOs. Das die PDO auslösende Ereignis ist der Empfang der Sync-Nachricht. Die Sync-Nachricht wird von einem Teilnehmer zentral versendet. Es muss nicht unbedingt das Gerät mit der NMT-Master-Funktion (Netzwerkmanagement-Master) sein. Alle CANopen-Geräte, die synchrone PDOs besitzen, übertragen nach dem Empfang der Sync-Nachricht die entsprechenden PDOs. Damit sich schnell und langsam ändernde Prozessdaten in dem System befinden können, kann der Systemintegrator festlegen, ob ein synchrones PDO auf den Empfang jeder, jeder zweite, usw. Sync-Nachricht reagieren soll. Durch ein optimiertes PDO-Mapping (alle sich langsam ändernden Prozessdaten in ein PDO und sich schneller ändernde Prozessdaten in andere PDOs) kann man so die PDO-Übertragung bezüglich der Buslast optimieren. Selbstverständlich muss der Systementwickler darauf achten, dass die Sync-Zykluszeiten so gewählt sind, dass keine Prozessdaten verloren gehen.

Wird ein Empfangs-PDO als synchron konfiguriert, trägt der CANopen-Protokoll-Stack die empfangenen Prozessdaten erst nach dem Empfang der folgenden Sync-Nachricht in das CANopen-Objektverzeichnis ein. Somit hat man ein komplett synchrones PDO-Verhalten: Die synchronen Sende-PDOs werden gleichzeitig getriggert und die empfangenen synchronen Prozessdaten werden mit der nächsten Sync-Nachricht gleichzeitig in allen Geräten verarbeitet. Dieses synchrone Verhalten wird beispielsweise in Mehrachssteuerungen angewendet. Es eignet sich aber auch zur zeitgleichen Erfassung von Messdaten.

Um die Buslast weiter zu reduzieren, hat der Systementwickler in CANopen die Möglichkeit, PDOs auch azyklisch zu übertragen, d. h., diese PDOs werden nur gesendet, wenn die Sync-Nachricht und ein spezifisches Ereignis (z. B. die Wertänderung eines gemappten Prozessdatums) eingetreten ist. So kann man nicht nur die Buslast über die Zeit optimal verteilen, sondern auch noch die Buslast reduzieren.

Eine weitere interessante Möglichkeit ist die unterschiedliche Konfiguration von Sende- und Empfangs-PDO. So kann man beispielsweise das Sende-PDO als synchron konfigurieren und die korrespondierenden Empfangs-PDO als asynchron. So erhält man zeitgleich erfasste Prozessdaten, die in den empfangenden Geräten sofort verarbeitet werden. Man kann aber auch PDOs asynchron senden und synchron empfangen. Dann hat man eine zeitgleiche Verarbeitung der ereignis-getriggerten Prozessdaten.

Der Entwickler von CANopen-Geräten muss allerdings sicherstellen, dass zum Zeitpunkt des Empfangs der Sync-Nachricht die Prozessdaten aktualisiert wurden, insbesondere wenn das Gerät intern die Prozessdaten periodisch auswertet. Da der Sync-Zyklus nicht mit der in der internen Verarbeitung synchronisiert ist, kann es dazu führen, dass die Prozessdaten erst nach dem Senden der synchronen PDOs aktualisiert werden. Um dieses Problem zu vermeiden, kann man den internen Verarbeitungszyklus mit der Sync-Periode synchronisieren oder intern die Prozessdaten ereignis-orientiert verarbeiten. Zu Letzterem ist allerdings ein lokales Echtzeit-Betriebssystem erforderlich.

In einigen Anwendungen benötigt man für eine optimale Buslastverteilung mehrere Sync-Nachrichten. Dies wird in CANopen virtuell mit dem Sync-Zähler erreicht. Der 1-Byte-Sync-Zähler wird optional in der Sync-Nachricht übertragen. Dieser ist ab der CANopen-Spezifikation Version 4.2 verfügbar. In dem Sync-Counter-Überlauf-Parameter legt der Systementwickler fest, bei welchem Wert der Zähler überläuft und wieder bei „1“ startet. In jedem synchron gesendeten PDO muss der Systementwickler den Startwert konfigurieren (Sync-Start-Value). Reagiert die synchronen Sende-PDOs nicht auf jede Sync-Nachricht, so muss der Systementwickler darauf achten, dass Startwert und Anzahl der „bedienten“ Sync-Nachrichten nicht zu einer ungleichmäßig verteilten Buslast führen. Ein einfaches Beipsiel zeigt die Abbildung: Der Sync-Counter läuft beim Wert „2“ über und startet wieder mit dem Wert „1“. Bis auf ein PDO reagieren alle auf jede zweite Sync-Nachricht. Nur ein PDO „bedient“ jede vierte Sync-Nachricht. Selbstverständlich kann man mit diesem erweiterten Sync-Verfahren auch komplexere Szenarien realisieren.

Konfigurierbare PDO-Priorität

Um das Verhalten optimal an die Anwendung anzupassen, kann der Systementwickler jedem Sende-PDO ein definierte Priorität für den Buszugriff zuweisen. Dies erfolgt über die Konfiguration der COB-ID-Parameter, in den die CAN-Priorität festgelegt wird. Prinzipiell ist es sinnvoll, den synchronen PDOs eine höhere Priorität als den asynchron übertragenen PDOs zuzuordnen. Doch Ausnahmen bestätigen auch hier die Regel: Es mag aus Sicht der Anwendung extrem wichtige PDOs geben, die deshalb eine höhere Priorität als die Synchronen PDOs aufweisen müssen. Der Anwender kann also auch diesbezüglich flexibel das Systemverhalten festlegen.

PDO-Querkommunikation

In CANopen hat der Systementwickler viele Freiheitsgrade bei der Konfiguration der PDOs. Neben dem konfigurierbaren Inhalt (PDO-Mapping), der einstellbaren Übertragungs- und Empfangsart (PDO-Transmission-Typ) und der Priorisierung von PDOs kann der Systementwickler auch noch eine PDO-Querkommunikation festlegen. In vielen Master/Slave-Kommunikationssystemen sendet und empfängt der Master alle Prozessdaten. Die von den Sensoren erfassten Prozessdaten werden also erst im nächsten Buszyklus an die Aktuatoren gesendet. Dies erfordert schnelle Kommunikationsysteme, um die Verzögerungen beim Empfang der Sensordaten in den Aktuatoren möglichst gering zu halten. Eine direkte Kommunikation zwischen Sensoren und Aktuatoren vermeidet diese Verzögerung. In CANopen kann man die PDOs so konfigurieren, dass alle an einem Prozessdatum interessierten Empfänger, das PDO direkt empfangen (PDO-Multicast, PDO-Broadcast). Diese als PDO-Linking bezeichnete Konfigurationsoption ist vom Systementwickler vorzunehmen.

Alle beschriebenen PDO-Konfigurationsoptionen kann der Systementwickler sozusagen von Hand einstellen. Um ihm die Arbeit zu erleichtern, bieten einige Firmen Software-Werkzeuge an, mit denen man die PDO-Konfiguration automatisch oder halb-automatisch vornehmen kann. Durch die Standardisierung der PDO-Parameter sind die Tools in der Lage, die Fähigkeiten eines CANopen-Gerätes zu erkennen und dem Systementwickler eine optimale PDO-Konfiguration „vorzuschlagen“. Sicherlich hängt die Qualität der vorgeschlagenen PDO-Kommunikation von den implementierten Algorithmen ab. Deshalb bieten die Konfigurationstools die Möglichkeit, die PDO-Konfiguration von Hand nachzubessern. Mit entsprechenden Simulationstools kann man dies sogar vor der Systemimplementierung testen.

Keine relativen Daten übertragen

Da Prozessdatenobjekte in einem CAN-Datenframe übertragen werden, müssen die übertragenen Prozessdaten immer absolut sein. Das CAN-Protokoll spezifiziert nämlich eine unterschiedliche Interpretation für Sender und Empfänger, wenn das letzte Bit des EOF-Feldes dominant gestört ist. Die Empfänger haben zu diesem Zeitpunkt die Nachricht als korrekt akzeptiert und interpretieren das dominante Bit als Überlast-Bedingung. Der Sender betrachtet das dominante Bit dagegen als einen Fehler und überträgt deshalb die Nachricht noch einmal. Die Empfänger erhalten also das PDO zweimal. Bei einer Übertragung von relativen Daten (z.B. Deltawerte oder Inkrementen) würde dies zu einem applikativen Fehlverhalten führen. Beispiel: Das Kommando „erhöhe die Temperatur um 10 °C“ würde doppelt ausgeführt zu einer unerwünscht hohen Temperatur führen!

Holger Zeltwanger, Managing Director, CAN in Automation

(ID:296484)