Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
Rasenmaehroboter fuer schwierige und grosse Gaerten im Test

(CANopen)
K (Weblinks)
 
(26 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
==CAN-BUS==
 
==CAN-BUS==
CAN ist ein 1983 von Robert Bosch GmbH entwickeltes Bussystem, das zunächst in der Automobilindustrie für die Onboardkommunikation eingesetzt wurde. In den folgenden Jahren fand es jedoch auch vielseitigen Einsatz in der Industrie. Aufgrund seiner Echtzeitfähigkeit, seiner ausgeprägten Fehlererkennungsmechanismen und Einfachheit kommt es Heutsotage in den unterschiedlichsten Bereichen zum Einsatz.
+
CAN ist ein 1983 von Robert Bosch GmbH entwickeltes Bussystem, das zunächst in der Automobilindustrie für die Onboardkommunikation eingesetzt wurde. In den folgenden Jahren fand es jedoch auch vielseitigen Einsatz in der Industrie. Aufgrund seiner Echtzeitfähigkeit, seiner ausgeprägten Fehlererkennungsmechanismen und Einfachheit kommt es heutzutage in den unterschiedlichsten Bereichen zum Einsatz.
  
Man unterscheidet zwischen zwei Spezifikationen:
+
===CAN-Identifier und Kontrollfelder===
# Can Spezifizierung 2.0A Dies ist die "Basisspezifikation" 11Bit ID
+
 
# Can Spezifizierung 2.0B Erweiterung der ID auf 29Bit
+
----
 +
 
 +
 
 +
Eine CAN-Nachricht wird in einer für den CAN-Bus eigenen Form "verpackt". Diese Verpackung bezeichnet man als Rahmen. (Neudeutsch: Frame)
 +
 
 +
Innerhalb eines Frames gibt es 7 Kennfelder:
 +
 
 +
* Start-Bedingung
 +
* Message Identifier
 +
* Steuerbits
 +
* Daten (0...8 Bytes)
 +
* Prüfbits
 +
* Acknowledge Bit
 +
* Stop-Bedingung
 +
 
 +
Außerdem werden die Frames nach der Länge des Identifiers unterschieden:
 +
 
 +
* Standard Frame (11-Bit)
 +
* Extended Frame (29-Bit)
 +
 
 +
===Frame-Übersicht===
 +
 
 +
----
 +
 
 +
====11-Bit-Identifier====
 +
 
 +
[[Bild:11-Bit-Identfier.jpg]]
 +
 
 +
Übersicht eines kompletten Datenrahmens (11-Bit-Identifier)
 +
 
 +
[[Bild:11-Bit-Datenframe.jpg]]
 +
 
 +
 
 +
 
 +
====29-Bit-Identifer====
 +
 
 +
[[Bild:29-Bit-Identifier.jpg]]
 +
 
 +
Übersicht eines kompletten Datenrahmes (29-Bit-Identifier)
 +
 
 +
[[Bild:29-Bit-Datenframe.jpg]]
 +
 
 +
 
 +
 
 +
===Abkürzungen===
 +
----
 +
 
 +
 
 +
{| {{Blauetabelle}} width=100%
 +
|Abkürzung
 +
|Bezeichnung
 +
|<center>Funktion
 +
|-
 +
|'''SOF'''
 +
|Start Of File
 +
|dominates Datenbit, dient der Synchronisation
 +
|-
 +
|
 +
|Identifier
 +
|Prioritätsinformation und Information für den Empfänger für die Busarbitrierung
 +
|-
 +
|'''RTR'''
 +
|Remote Transmission Request
 +
|rezessives Datenbit, unterscheidet zwischen Datenbit (dominant)und Datenanforderungstelegramm (rezessiv)
 +
|-
 +
|'''IDE'''
 +
|Identifier Extension
 +
|
 +
|-
 +
|'''r0, r1'''
 +
|
 +
|reserviert
 +
|-
 +
|'''DLC'''
 +
|Data Length Code
 +
|Längeninformation der nachfolgenden Daten
 +
|-
 +
|'''DATA'''
 +
|
 +
|Daten des Telegramms
 +
|-
 +
|'''CRC'''
 +
|Cyclic Redundancy Check
 +
|Fehlercodekennzeichnung der vorangegangenen Informationen. Die CRC-Prüfsumme wird zur Fehlererkennung verwendet
 +
|-
 +
|'''ACK'''
 +
|Acknowledge
 +
|Rückmeldung des korrekten Empfangs von anderen Teilnehmern
 +
|-
 +
|'''EOF'''
 +
|End Of File
 +
|Ende des Datentelegramms (7 rezessive Bits)
 +
|-
 +
|'''IFS'''
 +
|Inter Frame Spacing
 +
|Kennzeichnung des Übertragungszeitraums einer korrekt empfangenen Nachricht
 +
|-
 +
|'''SRR'''
 +
|Substitute Remote Request
 +
|Ersetzt im Extended Frame das RTR Bit des Standard Frame. Ausserdem signalisieren die Empfänger dem Sender, daß das Telegramm korrekt empfangen wurde.
 +
|}
  
 
===Übertragung===
 
===Übertragung===
Beim CAN-Bus handelt es sich um ein multimasterfähiges Bussystem, das bis 1MBit/s spezifiziert ist. Allerdings ist hierbei zu beachten, dass die maximale Segmentlänge mit der Erhöhung der Baudrate sinkt.  
+
Beim CAN-Bus handelt es sich um ein multimasterfähiges Bussystem, das bis 1MBit/s spezifiziert ist. Allerdings ist dabei zu beachten, dass die maximale Segmentlänge mit der Erhöhung der Baudrate sinkt.  
  
 
====Ausdehnung / Baudrate / Kabel====
 
====Ausdehnung / Baudrate / Kabel====
Zeile 15: Zeile 115:
  
  
{| border=1 width=80%:)
+
{| {{Blauetabelle}} width=80%:)
 
|'''Datenrate'''
 
|'''Datenrate'''
 
|'''Bitzeit'''
 
|'''Bitzeit'''
Zeile 80: Zeile 180:
 
  |}
 
  |}
  
Übertragen werden die Signale über 2 Kupferleitungen, die jeweils mit Abschlusswiderständen(124Ohm), um Reflexionen zu vermeiden, versehen sind.
+
===Terminierung===
 +
 
 +
Übertragen werden die Signale über 2 Kupferleitungen, die laut Spezifikation mit zwei 120 Ohm-Widerständen an den Enden des Bussystems terminiert werden müssen. Eine Terminierung sollte prinzipiell auch schon bei kurzen Leitungen und niedrigen Baudraten erfolgen. Beide Widerstände dienen gleichzeitig als kombinierte Pullup- und Pulldown-Widerstände für alle Teilnehmer auf dem Bus. Ohne den Abschluss mit diesen Widerständen "hängt" das System potentialmäßig in der Luft.
 +
 
 +
Es ist möglich, den CAN-Bus, ausgehend von den beiden Hauptbusleitungen, als sternförmiges System aufzubauen. In diesem Fall müssen die Terminierungswiderstände andere Werte haben. Bei drei Widerständen wäre das 180 Ohm, bei 4 = 240 Ohm. Das nennt man '''Multiple Termination Concept''' und wird von der CAN-CiA als probates Mittel zur Verzweigung des Bussystems angegeben.
  
 
====Bittiming====
 
====Bittiming====
Zur Berechnung des Samplepoints, dies ist der Zeitpunkt, zudem auf die Leitung "gesehen" werden soll, welchen Zustand diese hat, wird in der Regel nur die Busgeschwindigkeit benötigt. Aus dieser ermittelt der Controller vier Werte:
+
Zur Berechnung des Samplepoints, - das ist der Zeitpunkt, zu dem auf die Leitung "gesehen" werden soll, welchen Zustand diese hat-, wird in der Regel nur die Busgeschwindigkeit benötigt. Aus dieser ermittelt der Controller vier Werte:
 
* Synchronisationssegment:
 
* Synchronisationssegment:
 
->Segment, das zum Synchronisieren des Nodes benötigt wird
 
->Segment, das zum Synchronisieren des Nodes benötigt wird
 
* Propagationssegment:
 
* Propagationssegment:
->Segment, das die Zeit darstellt, die das Signal zur Ausbreitung im Medium benäötigt
+
->Segment, das die Zeit darstellt, die das Signal zur Ausbreitung im Medium benötigt
 
* Phasensegment 1
 
* Phasensegment 1
 
* Phasensegment 2
 
* Phasensegment 2
Zeile 102: Zeile 206:
  
 
====Arbitrierungsprozess====
 
====Arbitrierungsprozess====
 +
 +
Durch die Multimaster-Funktionalität sind in einem CAN-Bus-Netzwerk prinzipiell alle Teilnehmer gleichberechtigt. Durch die Buskonzeption ist kein sogenanntes "Frage/Antwort-Verhalten" vorgesehen. Jeder Teilnehmer kann und soll seine Datenübertragung selbstständig beginnen. Die Arbitrierung soll innerhalb einer Nachricht und ohne diese zu zerstören erfolgen.
 +
 +
Im CAN-Telegramm entspricht ein "aktiver" bzw. dominanter Pegel einer "0", während ein "passiver" bzw. rezessiver Pegel mit einer "1" bezeichnet wird. Somit überschreibt grundsätzlich ein dominanter Pegel einen rezessiven Pegel. Ein CAN-Knoten, der einen rezessiven Pegel senden will, wird durch den dominant sendenden Knoten überschrieben.
 +
 +
Alle CAN-Knoten beobachten (hören) gleichzeitig auf dem Bus mit. Solange der Bus durch ein Sendetelegramm belegt ist, wird kein weiterer Sendevorgang gestartet. Der aktuelle Buszustand wird daher immer mit dem eigenen Sendeframe verglichen.
 +
 +
Bei gleichzeitiger Übertragung mehrerer Controller, entscheidet das erste dominante Bit auf dem Bus über die Priorität der Nachricht (Dominanz hat Vorrang). Wenn nun ein CAN-Knoten, dessen Nachricht mit einem rezessiven Pegel beginnt, auf dem Bus einen dominanten Pegel erkennt, so unterbricht dieser Knoten seine Übertragung und versucht zu einem späteren Zeitpunkt diese Nachricht erneut zu schreiben. Dadurch bleibt die wichtigere Nachricht auf dem Bus fehlerfrei erhalten. Diese Nachricht enthält den kleinsten Identifier.
 +
 +
Der Samplepoint liegt bei 3/4 einer Bitzeit. Somit ergeben sich folgende Eigenschaften:
 +
 +
* Eine "0" im CAN-Telegramm repräsentiert den dominanten Pegel auf dem Bus. Daraus folgt, dass CAN-Identifier mit niedrigeren Zahlen, eine höhere Priorität aufweisen. Je niedriger der Identifier gewählt wird, desto wichtiger wird die Nachricht.
 +
 +
* Die Festlegung der Priorität erfolgt immer innerhalb eines Bits. Somit müssen alle Teilnehmer des Netzwerkes innerhalb einer Leitungsverzögerung von 1 Bit (eigentlich 3/4) liegen. Das beinhaltet den Hin- und Rückweg des Signals.
 +
 +
* Die Arbitrierung muss innerhalb des Identifiers erfolgen. Somit darf es zu jedem Identifier nur einen Sender geben. Dieser Identifier darf jedoch von mehreren CAN-Knoten empfangen werden.
  
 
====Fehlererkennung====
 
====Fehlererkennung====
  
 
* Bitfehler
 
* Bitfehler
* CRC - Fehler
+
* CRC-Fehler
* Ack - Fehler
+
* Ack-Fehler
* Format - Fehler
+
* Format-Fehler
* Stuffbit - Fehler
+
* Stuffbit-Fehler
 
+
  
 
==CANopen==
 
==CANopen==
Zeile 118: Zeile 237:
 
* Arbitrierungsprozess
 
* Arbitrierungsprozess
 
* Fehlererkennung
 
* Fehlererkennung
 +
 +
Prinzip:
 +
Der CAN-Bus weist unter normalen Betriebsbedingungen eine hohe elektrische Störsicherheit auf, die dadurch erreicht wird, daß ein Signal auf zwei Leitungen gleichzeitig mit einer gegensinnigen Potentialänderung abgebildet wird. In die Leitung eingestreute Störungen wirken auf beide Leitungen in die gleiche Richtung. Da die beiden differentiellen Leitungen jedoch immer gegensinnige Pegel haben, bleibt die Differenz des Signals auch bei Störungen erhalten.
 +
 +
Dieses Verfahren nennt man Gleichtaktunterdrückung oder auch Common Mode Rejection Ratio (CMRR)
 +
 +
[[Bild:Signale-can-bus.jpg]]
 +
 
* CANopen
 
* CANopen
 +
 +
 +
==Weblinks==
 +
 +
*[http://www.can-cia.org/ CAN-CiA - Can in Automation]
 +
*[http://www.sae.org/products/j1939a.htm SAE-J-1939 - CAN für Dieselmotoren]
 +
*[http://www.amazon.de/exec/obidos/ASIN/3800724480/qid%3D1138867611/303-9918464-0289067/ Buchempfehlung: CANopen von Holger Zeltwanger ISBN 3-8007-2448-0]
  
  
 
[[Kategorie:Grundlagen]]
 
[[Kategorie:Grundlagen]]
 +
[[Kategorie:Kommunikation]]
 
[[Kategorie:Microcontroller]]
 
[[Kategorie:Microcontroller]]
 +
 +
 +
{{Ausbauwunsch|Mehr Grundlagen und vor allem Programmbeispiele etc.}}

Aktuelle Version vom 21. Mai 2010, 10:14 Uhr

CAN-BUS

CAN ist ein 1983 von Robert Bosch GmbH entwickeltes Bussystem, das zunächst in der Automobilindustrie für die Onboardkommunikation eingesetzt wurde. In den folgenden Jahren fand es jedoch auch vielseitigen Einsatz in der Industrie. Aufgrund seiner Echtzeitfähigkeit, seiner ausgeprägten Fehlererkennungsmechanismen und Einfachheit kommt es heutzutage in den unterschiedlichsten Bereichen zum Einsatz.

CAN-Identifier und Kontrollfelder



Eine CAN-Nachricht wird in einer für den CAN-Bus eigenen Form "verpackt". Diese Verpackung bezeichnet man als Rahmen. (Neudeutsch: Frame)

Innerhalb eines Frames gibt es 7 Kennfelder:

  • Start-Bedingung
  • Message Identifier
  • Steuerbits
  • Daten (0...8 Bytes)
  • Prüfbits
  • Acknowledge Bit
  • Stop-Bedingung

Außerdem werden die Frames nach der Länge des Identifiers unterschieden:

  • Standard Frame (11-Bit)
  • Extended Frame (29-Bit)

Frame-Übersicht


11-Bit-Identifier

11-Bit-Identfier.jpg

Übersicht eines kompletten Datenrahmens (11-Bit-Identifier)

11-Bit-Datenframe.jpg


29-Bit-Identifer

29-Bit-Identifier.jpg

Übersicht eines kompletten Datenrahmes (29-Bit-Identifier)

29-Bit-Datenframe.jpg


Abkürzungen



Abkürzung Bezeichnung
Funktion
SOF Start Of File dominates Datenbit, dient der Synchronisation
Identifier Prioritätsinformation und Information für den Empfänger für die Busarbitrierung
RTR Remote Transmission Request rezessives Datenbit, unterscheidet zwischen Datenbit (dominant)und Datenanforderungstelegramm (rezessiv)
IDE Identifier Extension
r0, r1 reserviert
DLC Data Length Code Längeninformation der nachfolgenden Daten
DATA Daten des Telegramms
CRC Cyclic Redundancy Check Fehlercodekennzeichnung der vorangegangenen Informationen. Die CRC-Prüfsumme wird zur Fehlererkennung verwendet
ACK Acknowledge Rückmeldung des korrekten Empfangs von anderen Teilnehmern
EOF End Of File Ende des Datentelegramms (7 rezessive Bits)
IFS Inter Frame Spacing Kennzeichnung des Übertragungszeitraums einer korrekt empfangenen Nachricht
SRR Substitute Remote Request Ersetzt im Extended Frame das RTR Bit des Standard Frame. Ausserdem signalisieren die Empfänger dem Sender, daß das Telegramm korrekt empfangen wurde.

Übertragung

Beim CAN-Bus handelt es sich um ein multimasterfähiges Bussystem, das bis 1MBit/s spezifiziert ist. Allerdings ist dabei zu beachten, dass die maximale Segmentlänge mit der Erhöhung der Baudrate sinkt.

Ausdehnung / Baudrate / Kabel

Bei einer Oszillatorfrequenz von 16MHz und einer Einfachabtastung(siehe Bittiming) kann man nach folgender Tabelle gehen:



Datenrate Bitzeit Quanta/Bit Time Quantum (TQ) SP Location Länge
1Mbit/s 1µs 8 125ns 6TQ 25m
800kbit/s 1,25µs 10 125ns 8TQ 50m
500kbit/s 2µs 16 125ns 14TQ 100m
250kbit/s 4µs 16 250ns 14TQ 250m
125kbit/s 8µs 16 500ns 14TQ 500m
50kbit/s 20µs 16 1,25µs 14TQ 1000m
20kbit/s 50µs 16 3,125µs 14TQ 2500m
10kbit/s 100µs 16 6,25µs 14TQ 5000m

Terminierung

Übertragen werden die Signale über 2 Kupferleitungen, die laut Spezifikation mit zwei 120 Ohm-Widerständen an den Enden des Bussystems terminiert werden müssen. Eine Terminierung sollte prinzipiell auch schon bei kurzen Leitungen und niedrigen Baudraten erfolgen. Beide Widerstände dienen gleichzeitig als kombinierte Pullup- und Pulldown-Widerstände für alle Teilnehmer auf dem Bus. Ohne den Abschluss mit diesen Widerständen "hängt" das System potentialmäßig in der Luft.

Es ist möglich, den CAN-Bus, ausgehend von den beiden Hauptbusleitungen, als sternförmiges System aufzubauen. In diesem Fall müssen die Terminierungswiderstände andere Werte haben. Bei drei Widerständen wäre das 180 Ohm, bei 4 = 240 Ohm. Das nennt man Multiple Termination Concept und wird von der CAN-CiA als probates Mittel zur Verzweigung des Bussystems angegeben.

Bittiming

Zur Berechnung des Samplepoints, - das ist der Zeitpunkt, zu dem auf die Leitung "gesehen" werden soll, welchen Zustand diese hat-, wird in der Regel nur die Busgeschwindigkeit benötigt. Aus dieser ermittelt der Controller vier Werte:

  • Synchronisationssegment:

->Segment, das zum Synchronisieren des Nodes benötigt wird

  • Propagationssegment:

->Segment, das die Zeit darstellt, die das Signal zur Ausbreitung im Medium benötigt

  • Phasensegment 1
  • Phasensegment 2

Zwischen Phasensegment 1 und 2 liegt der Samplepoint.

Bit Stuffing

Da beim CAN auch während der Datenübertragung synchronisiert wird, wird nach fünf Bits gleicher Polarität in den Datenfluss ein Bit eingebaut, welches den Pegel ändert. Diese Bits nennt man Stuffbits. Der Empfänger destufft die Daten wieder, sodass die Daten für den Empfängercontroller genauso aussehen, wie für den Sender. Die maximale Anzahl der in ein Telegramm eingefügten Stuffbits errechnet sich nach folgender Formel:

 max'_stuff_'=(34 + 8 Dlc -1)/4 

Protokoll

Arbitrierungsprozess

Durch die Multimaster-Funktionalität sind in einem CAN-Bus-Netzwerk prinzipiell alle Teilnehmer gleichberechtigt. Durch die Buskonzeption ist kein sogenanntes "Frage/Antwort-Verhalten" vorgesehen. Jeder Teilnehmer kann und soll seine Datenübertragung selbstständig beginnen. Die Arbitrierung soll innerhalb einer Nachricht und ohne diese zu zerstören erfolgen.

Im CAN-Telegramm entspricht ein "aktiver" bzw. dominanter Pegel einer "0", während ein "passiver" bzw. rezessiver Pegel mit einer "1" bezeichnet wird. Somit überschreibt grundsätzlich ein dominanter Pegel einen rezessiven Pegel. Ein CAN-Knoten, der einen rezessiven Pegel senden will, wird durch den dominant sendenden Knoten überschrieben.

Alle CAN-Knoten beobachten (hören) gleichzeitig auf dem Bus mit. Solange der Bus durch ein Sendetelegramm belegt ist, wird kein weiterer Sendevorgang gestartet. Der aktuelle Buszustand wird daher immer mit dem eigenen Sendeframe verglichen.

Bei gleichzeitiger Übertragung mehrerer Controller, entscheidet das erste dominante Bit auf dem Bus über die Priorität der Nachricht (Dominanz hat Vorrang). Wenn nun ein CAN-Knoten, dessen Nachricht mit einem rezessiven Pegel beginnt, auf dem Bus einen dominanten Pegel erkennt, so unterbricht dieser Knoten seine Übertragung und versucht zu einem späteren Zeitpunkt diese Nachricht erneut zu schreiben. Dadurch bleibt die wichtigere Nachricht auf dem Bus fehlerfrei erhalten. Diese Nachricht enthält den kleinsten Identifier.

Der Samplepoint liegt bei 3/4 einer Bitzeit. Somit ergeben sich folgende Eigenschaften:

  • Eine "0" im CAN-Telegramm repräsentiert den dominanten Pegel auf dem Bus. Daraus folgt, dass CAN-Identifier mit niedrigeren Zahlen, eine höhere Priorität aufweisen. Je niedriger der Identifier gewählt wird, desto wichtiger wird die Nachricht.
  • Die Festlegung der Priorität erfolgt immer innerhalb eines Bits. Somit müssen alle Teilnehmer des Netzwerkes innerhalb einer Leitungsverzögerung von 1 Bit (eigentlich 3/4) liegen. Das beinhaltet den Hin- und Rückweg des Signals.
  • Die Arbitrierung muss innerhalb des Identifiers erfolgen. Somit darf es zu jedem Identifier nur einen Sender geben. Dieser Identifier darf jedoch von mehreren CAN-Knoten empfangen werden.

Fehlererkennung

  • Bitfehler
  • CRC-Fehler
  • Ack-Fehler
  • Format-Fehler
  • Stuffbit-Fehler

CANopen

ToDo:

  • Protokoll
  • Arbitrierungsprozess
  • Fehlererkennung

Prinzip: Der CAN-Bus weist unter normalen Betriebsbedingungen eine hohe elektrische Störsicherheit auf, die dadurch erreicht wird, daß ein Signal auf zwei Leitungen gleichzeitig mit einer gegensinnigen Potentialänderung abgebildet wird. In die Leitung eingestreute Störungen wirken auf beide Leitungen in die gleiche Richtung. Da die beiden differentiellen Leitungen jedoch immer gegensinnige Pegel haben, bleibt die Differenz des Signals auch bei Störungen erhalten.

Dieses Verfahren nennt man Gleichtaktunterdrückung oder auch Common Mode Rejection Ratio (CMRR)

Signale-can-bus.jpg

  • CANopen


Weblinks


Dieser Artikel ist noch lange nicht vollständig. Der Auto/Initiator hofft das sich weitere User am Ausbau des Artikels beteiligen.

Das Ergänzen ist also ausdrücklich gewünscht! Besonders folgende Dinge würden noch fehlen:

Mehr Grundlagen und vor allem Programmbeispiele etc.


LiFePO4 Speicher Test