Forum: Mikrocontroller und Digitale Elektronik CAN-Bus: RTR-Telegramm mit Nutzdaten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernie B. (berbeer)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich finde grad kaum brauchbare Infos zu den Möglichkeiten eines 
RTR-Telegramms beim CAN.

Mit dem RTR wird ja ein Teilnehmer aufgefordert, Daten zu senden. In der 
Regel enthält das RTR keine Nutzdaten und die Datenlänge wird oft zu 0 
gesetzt.
Nach CAN soll aber die Länge der erwarteten Daten eingefügt werden.
Heißt das, daß das RTR-Telegram zwar eine Datenlänge eingetragen hat, 
tatsächlich aber keine Nutzdaten transportiert?

Eigentlich möchte ich das RTR-Telegramm nutzen, um einem Teilnehmer 
mitzuteilen, welche Daten ich genau haben möchte: "Sende mir mal 
Datenpaket Nr. xy".
Dies bedeutet, ich muss xy im Telegramm mitsenden.
Da im System der ID-Bereich festgelegt ist, kann dafür kein neuer ID 
verwendet werden.

Funktioniert das ?

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
RTR Protokolle sind zwas spezifiziert in alten CiA301, sollten aber 
nicht mehr verwendet werden. Es gibt ggf. Inkonsistenzen auf dem Bus.
Stattdessen lieber Zeitgesteuert Nachrichten senden.

Zur Erklärung wie das RTR prinzipiell funktioniert:
Beim RTR Request wird vom Anforderer CAN-ID ohne Daten gesendet.
Der Empfänger sendet daraufhin automatisch auf der gleichen CAN-ID 
vorher definierte Daten zurück. "Automatisch" bedeutet, dass dies der 
CAN Chip ohne Zutun der Anwendung / des CAN-Stacks tut. Er sendet die 
Daten, welche zuletzt von der Anwendung in das Senderegister geschrieben 
wurden.

von Martin H. (horo)


Bewertung
0 lesenswert
nicht lesenswert
Die Idee dahinter ist, dass wenn gleichzeitig ein Knoten per RTR Daten 
anfordert, die ein anderer Knoten mit der gleichen Message-ID gerade 
senden will, die Datenaussendung bei der Arbitrierung gewinnt (das 
RTR-Bit ist rezessiv) und die somit nicht mehr erforderliche 
RTR-Anforderung anschließend entfallen kann - eine HW-unterstützte 
Funktion z.B. in den ersten Intel-CAN-Bausteinen 82526.

Ciao, Martin

von Clemens S. (zoggl)


Bewertung
-1 lesenswert
nicht lesenswert
Bernie B. schrieb:
> Eigentlich möchte ich das RTR-Telegramm nutzen, um einem Teilnehmer
> mitzuteilen, welche Daten ich genau haben möchte: "Sende mir mal
> Datenpaket Nr. xy".

nop, das geht nicht. das wird niemand auf dem Bus verstehen. das kann 
normale CAN HW auch nicht, weil das RTR Bit rezessiv ist.

mach doch eine ID für Datenabfrage und eine für Daten senden. und 
vergiss nicht in der Antwort kenntlich zu machen WORAUF es die Antwort 
ist. (nicht dass sich zwei fragen überschneiden und die Antwort dann 42 
ist.


schau mal bei CANopen vorbei. da gibt es dafür Lösungen und fixe IDs auf 
denen gesendet und empfangen wird.

sg

von Martin H. (horo)


Bewertung
0 lesenswert
nicht lesenswert
Clemens S. schrieb:
> nop, das geht nicht. das wird niemand auf dem Bus verstehen. das kann
> normale CAN HW auch nicht, weil das RTR Bit rezessiv ist.

Das ist kein Argument, rezessiv ist nur bei der Arbitrierung 
interessant. Kein Problem, wenn der Bus inaktiv ist - auch kein Problem, 
wenn Deine Anfrage (die ID) eine höhere Priorität hat als ein anderer 
gleichzeitiger Versuch, auf den Bus zuzugreifen. Auch die Adressbits 
können rezessiv sein (alle Bits mit Wert 1) und trotzdem kannst Du 
Nachrichten übertragen, deren ID > 0 ist.

von Clemens S. (zoggl)


Bewertung
0 lesenswert
nicht lesenswert
Martin H. schrieb:
> rezessiv ist nur bei der Arbitrierung
> interessant

nein, Dominant und Rez gelten für die gesammte Nachricht.
du sendest dein RTR mit Payload und der Sender sendet seine Daten (mit 
gleicher ID, sonst wäre es ja kein RTR).
Damit hast du einen Kauderwelsch aus beiden Telegrammen. Dann wird 
beides erneut gesendet, weil die CRCs nicht stimmen => Mist per Design. 
und daher unterstützt auch keine HW das.

wenn du lust und laune hast dir alles selbst zu schnitzen go for it.

es gibt CAN als Softwareimplementation die du an deine Bedürfnisse 
anpassen kannst:
http://caraca.sourceforge.net

sg

von Thomas F. (igel)


Bewertung
0 lesenswert
nicht lesenswert
Bernie B. schrieb:
> Eigentlich möchte ich das RTR-Telegramm nutzen, um einem Teilnehmer
> mitzuteilen, welche Daten ich genau haben möchte: "Sende mir mal
> Datenpaket Nr. xy".

Das Konzept hinkt schon:
Mit RTR teilt man dem Sender mit welche Botschaft, also welche ID, 
gesendet werden soll. Der Inhalt (Nutzdaten) einer Botschaft mit eigener 
ID sollte nicht nach irgendeiner Anforderung variieren (Ausnahme echtes 
Multiplex, aber das funktioniert auch anders).

Unterschiedliche Daten von einem Sender sollten in Botschaften mit 
jeweils eigener ID über den Bus gehen. Falls man irgendwann mal noch 
einen Zuhörer auf den Bus klemmt so muss dieser in seiner Software auch 
deine RTR-Anforderung erkennen und sich merken damit er dann die 
eigentliche Botschaft auch wieder richtig in Nutzdaten dekodieren kann. 
Das ist umständlich und fehleranfällig.

von Martin H. (horo)


Bewertung
0 lesenswert
nicht lesenswert
Clemens S. schrieb:
> nein, Dominant und Rez gelten für die gesammte Nachricht.

Du solltest Dir mal anschauen, wie die bitweise Arbitrierung läuft. 
Wenn zwei oder mehr Knoten gleichzeitig zu senden beginnen, dann 
vergleichen sie im Arbitrierungsbereich (11 ID-Bits und RTR-Bit) Bit 
für Bit ihre Daten (TxD) mit dem Buszustand (RxD). Sobald dort ein 
rezessiv gesendetes Bit als dominant zurückgelesen wird stoppen sie ihre 
Aussendung und werden passiv auf TxD und lauschen nur noch an RxD.

siehe 
https://de.wikipedia.org/wiki/Controller_Area_Network#Arbitrierung,_Priorit%C3%A4t
"Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf 
Basis der Identifier der zu sendenden Nachrichten aufgelöst. Dazu 
überwacht jeder Sender den Bus, während er gerade den Identifier sendet. 
Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste dominante 
Bit eines der beiden das entsprechend rezessive des anderen, was dieser 
erkennt und seinen Übertragungsversuch beendet. Verwenden beide 
Teilnehmer den gleichen Identifier, wird nicht sofort ein Error-Frame 
erzeugt (siehe Frame-Aufbau), sondern erst bei einer Kollision innerhalb 
der restlichen Bits, was durch die Arbitrierung ausgeschlossen sein 
sollte. Daher empfiehlt der Standard, dass ein Identifier auch nur von 
maximal einem Teilnehmer verwendet werden soll."


Als Sonderfall können aber mehrere Knoten eine RTR-Anforderung senden, 
das entspricht auch dem CAN-Datenflussmodell - ein Sender und mehrere 
mögliche Empfänger.

Ciao, Martin

P.S.: Die Jungs und Mädels bei Bosch haben lange Jahre über jedes Bit im 
CAN-Protokoll gerungen, das ist schon ok so.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.