Instructions

Protokollanalyse
R&S
®
Scope Rider RTH
206Bedienhandbuch 1326.1578.03 ─ 10
bevor er versucht, eine Nachricht zu senden. Kollisionen werden durch eine bitweise
Arbitrierung, die nicht destruktiv ist, aufgelöst.
Jede Nachricht hat eine Priorität, die sich aus dem Identifier-Wert ergibt - je niedriger
der Wert, desto höher die Priorität. Ein dominantes Bit aus der Nachricht mit der höch-
sten Priorität überschreibt die rezessiven Bits auf dem Bus. Erkennt ein Knoten, dass
der Bus bereits eine Nachricht mit einer höheren Priorität empfängt, stoppt er die Über-
tragung und wartet auf das Ende der aktuellen Übertragung, bevor er erneut mit der
Übertragung beginnt.
Frametypen
Das CAN/CAN FD-Protokoll definiert folgende Frametypen:
●
Daten: Zur Übertragung von Informationen
●
Remote: Zur Anforderung von Informationen. Der Zielknoten sendet diesen Frame
zur Quelle, um Daten anzufordern. Dieser Frametyp wird nur von CAN verwendet.
●
Fehler: Zeigt an, dass ein Busknoten einen Übertragungsfehler erkannt hat.
●
Überlast: Dient einem Busknoten zur Anforderung einer Übertragungsverzögerung.
CAN-Datennachrichtenformat
Das CAN-Protokoll definiert zwei Formate für den Datenframe: das Basisformat und
das erweiterte Format. Die Datenframes sind wie folgt aufgebaut:
Bild 9-16: CAN-Basisframe
Bild 9-17: Erweiterter CAN-Frame
Das Basisformat bzw. erweiterte Frameformat besteht aus folgenden Feldern:
●
SOF: Start of Frame. 1 dominantes Bit, das den Anfang der Nachricht markiert.
●
Identifier: 11/18-Bit-Identifier. Enthält Informationen zur Priorität der Nachricht.
CAN-Basisframes haben einen 11-Bit-Identifier, erweiterte CAN-Frames insgesamt
einen 29-Bit-Identifier.
●
RTR: Bit für Remote-Übertragungsanforderung. Dient zur Unterscheidung zwi-
schen Basisframes und erweiterten Frames. Es ist dominant für Basisdatenframes
und rezessiv für erweiterte Datenframes.
●
SRR: Substitute Remote Request. Ersetzt in erweiterten CAN-Frames das RTR-Bit
in Basisframes.
CAN und CAN FD (Optionen R&S
RTH-K3, R&S RTH-K9)