Finger weg von CAN Remote Frames!

CAN Remote Frames – auch als RTR (Remote Transmission) bezeichnet – sind in der Bosch CAN Spezifikation /1/ definiert, um einen CAN Data Frame mit dem gleichen CAN Identifier anzufordern. Die Unterschiede zu einem CAN Data Frame sind:

  • beim Remote Frame ist das RTR Bit nach dem Identifier immer rezessiv
  • der Remote Frame hat kein Datenfeld

CAN Remote Frame

CAN Remote Frame


Außer CANopen erlaubt kein mir bekanntes Higher-Layer Protokoll (HLP) die Verwendung von Remote Frames, in der SAE J1939 oder in DeviceNet ist die Verwendung sogar explizit verboten. Und dies hat einen guten Grund: Remote Frames führen in der Praxis zu erheblichen Problemen, die ich im folgenden beschreiben möchte.

Unterschiedliche Implementierungen

Für den Empfang von CAN Remote Frames existieren unterschiedliche Ansätze. Zum einen gibt es CAN Controller, die eine CAN Nachricht über ein RTR Bit kennzeichnen, wenn es in den Empfangspuffer geschrieben wird. Dieses muss dann per Software ausgewertet werden. Ein anderer Ansatz ist die Markierung eines CAN Message Buffers im CAN Chip mit einem Flag, der dann bei Eintreffen des Remote Frames automatisch den Data Frame sendet. Ob dieser CAN Message Buffer für Empfang oder Senden konfiguriert sein muss hängt von der Philosophie des Halbleiterherstellers ab, hier gibt es leider keinen Standard. Problematisch an der automatischen Aussendung des Data Frames ist aber, dass die Applikation erst nach der erfolgreichen Übertragung der Daten davon erfährt und somit den Inhalt des CAN Data Frames nicht mehr aktualisieren kann.

Prinzipielles Problem

Die Verwendung von CAN Controllern mit autonomer Reaktion auf CAN Remote Frames birgt ein potenzielles Risiko. Solange die Protocol Engine des Controllers unter Spannung steht und getaktet wird, erfolgt auch eine Antwort auf Remote Frames, selbst wenn der Rest des Microcontrollers bildlich gesprochen “in Flammen steht”. Man muss also schon tief in die Trickkiste greifen (wie beim CANopen Node-Guarding) um überhaupt sicher zu stellen, dass bei der Kommunikation über Remote Frames valide Daten von der Applikation gesendet werden.

Fehlerhafte Implementierungen

Leider existieren immer noch fehlerhafte Implementierungen des CAN Remote Frames auf dem Markt. Dies fängt damit an, dass der DLC in einem Remote Frame nicht korrekt ausgewertet wird und endet mit Chips, die bei Eintreffen eines Remote Frames mit einem Error Frame antworten. Für den Anwender, der überhaupt nicht weiß, welche CAN Controller in dem Gerät verbaut sind, wird damit die Fehlersuche zu einer echten Herausforderung. Daher kann meine Empfehlung nur lauten: “Finger weg von CAN Remote Frames!”

Vermeidung in CANopen

In /2/ ist die Problematik von CAN Remote Frames ausführlich erläutert und es wird erklärt, wie man auch CANopen Netzwerke ohne RTR betreiben kann. Die betroffenen CANopen Dienste sind zum einen das Node-Guarding und zum anderen PDO Nachrichten.

Das Node-Guarding wird einfach durch den Heartbeat ersetzt, was zudem den Vorteil hat, dass CANopen NMT Slave Geräte sich gegenseitig überwachen können (Node-Guarding kann nur vom NMT Master durchgeführt werden). In CoDeSys ist zur Überwachung der CANopen Teilnehmer immer noch Node-Guarding als Standard eingestellt, hier muss man den Haken einfach nur bei Heartbeat setzen.

Für das Anfordern von PDO Nachrichten besteht die Alternative, dies über eine SYNC Botschaft zu erreichen.

Referenzen

/1/ ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
/2/ CiA Application Note AN802 – CAN remote frames: Avoiding of usage, CiA specifications

Stichworte: , , ,

Geschrieben in: CAN, CANopen, Fachbeiträge


Hinterlasse eine Antwort