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 ?
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.
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
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
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.
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
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.