CANopen-Übertragung und -Überwachung

Einführung

CANopen ist ein offenes Kommunikationsprotokoll nach Industriestandard und eine Geräteprofil­spezifikation (EN 50325-4), die auf dem Controller Area Network-Protokoll (CAN) basiert. Das CAN-Protokoll (Schicht 7) wurde für integrierte Netzwerkanwendungen entwickelt und definiert Kommunikations- und Gerätefunktionen für CAN-basierte Systeme.

CANopen unterstützt sowohl die zyklische als auch die ereignisgesteuerte Kommunikation, sodass Sie die Buslast bei weiterhin kurzen Reaktionszeiten auf ein Minimum begrenzen können.

PDO: Process Data Object (Prozessdatenobjekt)

PDOs sind Objekte, die der Kommunikationsschnittstelle Prozessdaten liefern und den Austausch dieser Prozessdaten in Echtzeit ermöglichen. Der Satz PDOs in einem CANopen-Gerät beschreibt die impliziten Austauschvorgänge zwischen diesem Gerät und dessen Kommunikationspartnern im Netzwerk. Der Austausch der PDOs wird genehmigt, wenn sich das Gerät im Modus „OPERATIONAL“ befindet.

Es gibt zwei Arten von PDOs:

oSende-PDOs (TPDOs): Vom Gerät übertragene PDOs

oEmpfangs-PDOs (RPDOs): Vom Gerät empfangene PDOs

Übertragungsmodi

Der TM3 CANopen-Buskoppler unterstützt der Arten von PDO-Übertragungsmodi:

Mit ereignisgesteuerten PDOs sind darüber hinaus zwei weitere Optionen verknüpft:

oInhibit Time: Das Dienstprogramm „Inhibit Time“ ermöglicht die Festlegung einer minimalen Zeitverzögerung bis zur Übertragung eines neuen PDO. Dadurch wird die Überlastung des Busses vermieden, wenn zahlreiche Ereignisse kurz hintereinander auftreten. Die „Inhibit Time“ wird als Vielfaches von 100 μs ausgedrückt.

Diese Funktion ist für Übertragungen vom Typ 255 (Asynchron) verfügbar.

Die nachstehebde Tabelle enthält Beispielwerte:

oEvent Time: Die Event Time ermöglicht die Festlegung einer Zeitverzögerung, nach deren Ablauf die Übertragung eines PDO forciert wird, selbst wenn kein Statuswechsel erfolgt ist. Die Event Time wird in Millisekunden ausgedrückt.

Diese Funktion ist für Übertragungen vom Typ 255 (Asynchron) verfügbar.

Die nachstehebde Tabelle enthält Beispielwerte:

SDO: Service Data Object (Dienstdatenobjekt)

SDOs ermöglichen den Zugriff auf die Daten eines Geräts über explizite Requests. Der SDO-Dienst ist verfügbar, wenn sich das Gerät im Zustand 'OPERATIONAL' oder 'PRE-OPERATIONAL' befindet.

Es gibt zwei Arten von SDOs:

oLese-SDOs (Download-SDOs)

oSchreib-SDOs (Upload-SDOs)

Das SDO-Protokoll basiert auf einem Client/Server-Modell. Bei einem Download-SDO sendet der Client (in der Regel die Steuerung) einen Request mit Angabe des zu lesenden Objekts. Der Server (in diesem Fall der Buskoppler) gibt die im Objekt enthaltenen Daten zurück. Bei einem Upload-SDO sendet der Client (in der Regel die Steuerung) einen Request mit Angabe des Objekts, in das geschrieben werden soll, und des gewünschten Werts. Nach der Aktualisierung des Objekts gibt der Server (in diesem Fall der Buskoppler) eine Bestätigungsnachricht zurück.

Wenn ein SDO vom Server (Buskoppler) nicht verarbeitet werden kann, gibt er einen Fehlercode (Abbruchcode) zurück. Das gilt sowohl für Download-SDOs als auch für Upload-SDOs. Wenn der Server nicht innerhalb eines vorkonfigurierten Zeitraums (SDO-Timeout) antwortet, gibt der Client einen SDO-Timeout-Abbruchcode aus.

Fehlerkontrollprotokolle

Fehlerkontrollprotokolle ermöglichen die Erkennung von Kommunikationsfehlern im Netzwerk. Es sind zwei Protokolle vorhanden: Node Guarding und heartbeat. Diese zwei Überwachungsmecha­nismen sind insbesondere im CANopen-System von Bedeutung. Die mit dem Bus verbundenen Geräte geben ihre Präsenz in einer Betriebsart nicht regelmäßig bekannt, vor allem wenn Sie ereignisgesteuert sind.

HINWEIS: Ein CANopen-Gerät kann die Überwachung nicht gleichzeitig mithilfe beider Überwachungsmethoden unterstützen - Guarding und Hearbeat. Wenn von einem Gerät beide Konfiguration empfangen werden, verwendet es nur die Überwachungsmethode Hearbeat.

Node Guarding

In diesem Protokoll fragt der NMT-Master (in der Regel die Steuerung) jeden NMT-Slave (Buskoppler z. B.) in regelmäßigen Zeitabständen ab. Diese Zeitintervalle werden als Guard Time bezeichnet. Der Slave antwortet mit seinem NMT-Zustand. Wenn der Slave nach einem vorgegebenen Zeitraum, der so genannten Lifetime, keine Abfrage (Polling) empfängt, geht der Slave in den im Objekt 1029H definierten Zustand über und generiert ein life guarding-Ereignis. Der Buskoppler wechselt in den im Objekt 1029H (wenn das Objekt 1029H als Standard übernommen wurde) konfigurierten Zustand, die Fehlerausweichverwaltung wird aktiviert und ein Guarding-Ereignis generiert. Die Lifetime wird definiert wie folgt: Lifetime = Guard Time x Lifetime Factor. Das Objekt 100CH enthält den Parameter „Guard Time“, angegeben in Millisekunden. Das Objekt 100DH enthält den Parameter Lifetime Factor. Guard Time und Lifetime können für verschiedene Slaves unterschiedlich konfiguriert werden.

Wenn einer der zwei Parameter Lifetime Factor und Guard Time auf 0 gesetzt ist (Standardkonfi­guration), führt der Slave keine Überwachung durch. Um die Überwachung langfristig zu aktivieren, müssen Sie einen Wert (mindestens 2) in das Objekt 100DH eingeben und im Objekt 100CH eine Zeit in ms festlegen.

Typische Werte für den Parameter Guard Time liegen zwischen 200 ms und 2 s.

Um einen zuverlässigeren und sichereren Betrieb zu gewährleisten, müssen Sie für den Lifetime Factor (Objekt 100DH) mindestens den Wert eingeben. Wenn der Wert 1 verwendet wird und aufgrund der Verarbeitung von Nachrichten mit hoher Priorität oder einer internen Verarbeitung im Node Guarding-Master eine Verzögerung auftritt, kann es vorkommen, dass der Slave versehentlich in den im Objekt 1029H konfigurierten Zustand wechselt.

Die Überwachung erfolgt auf folgende Art und Weise:

HINWEIS: Selbst wenn die Überwachungsfunktion langfristig deaktiviert wird (die Register Guard Time und Lifetime-Factor sind auf 0 gesetzt), antwortet der Slave auf einen dezentralen Request des Masters. Für die Guarding-Nachricht entspricht der Initialwert des in der ersten Guarding-Nachricht gesendeten Toggle-Bit 0. Dann ändert sich das Toggle-Bit in jeder folgenden 'Guarding-Nachricht. Dadurch kann erkannt werden, wenn eine Meldung verloren geht.

Der Netzwerkzustand des Geräts wird anhand der folgenden verbleibenden Bits ausgewiesen:

Heartbeat-Mechanismus

Bei diesem Protokoll überträgt der Producer periodisch eine Heartbeat-Nachricht, je nach dem im Objekt 1017H (in Millisekunden) konfigurierten Parameter Producer Heartbeat Time. Für die für die Überwachung dieser Nachricht zuständigen Geräte wird im Objekt 1016H eine Consumer Heartbeat Time (in Millisekunden) festgelegt. Wenn die Heartbeat-Nachricht vom Producer nicht innerhalb des konfigurierten Zeitraums der Consumer-Geräte empfangen wird, generieren die Geräte ein Heartbeat-Ereignis. Der Buskoppler wechselt in den im Objekt 1029H konfigurierten CANopen-Zustand, die Fehlerausweichverwaltung wird aktiviert und ein Heartbeat-Ereignis generiert.

Die Heartbeat-Nachricht signalisiert den Gerätestatus in einem Byte, das sich aus Folgendem zusammensetzt:

oDas höherwertige Bit ist reserviert und weist immer den Wert 0 auf.

oDie 7 niederwertigen Bits enthalten den Status des Geräts, das die Heartbeat-Nachricht generiert hat.

Folgende Werte sind möglich: