Beschreibung des CAN-Bus
Artikel von Jürgen V.
CAN wurde von Bosch (das ist die Fabrik gleich um die Ecke bei mir) als Bussystem 1991 zum Einsatz in Kraftfahrzeugen entwickelt. Zwischenzeitlich erfreut sich CAN einer solchen Beliebtheit, daß es nahezu als Nachfolger der seriellen V24 Schnittstelle bezeichnet werden kann. Dies trifft vor allem bei technischen und industriellen Anwendungen zu, während im Konsum und PC Bereich offensichtlich die neuere USB Schnittstelle das Rennen gewinnt.
Insbesondere Halbleiterhersteller steigen auf breiter Front auf den CAN Bus ein, da im Automobilsektor wohl genügend Stückzahlen vorhanden sind. Neben externen CAN Schnittstellenchips gibt es vermehrt Single Chip Prozessoren die eine oder mehrere CAN Schnittstellen bereits beinhalten. Demgegenüber ist man bei anderen Feldbussystemen (Interbus, ASI, etc.) noch immer auf relativ spezielle Halbleiterbauteile und Software angewiesen.
Achtung: CAN wird sowohl von Bosch und Anderen über eine Vielzahl von Patenten geschützt. Dies ist eine kostenlose private Seite für Hobbybastler die ihr Skateboard mit einem CAN Anschluss nachrüsten, ihr Auto frisieren, oder sonst was mit CAN basteln wollen. Eine kommerzielle Nutzung ist nicht vorgesehen.
Elektrische Anbindung
Im Allgemeinen hat sich der ISO 11898 24V Standard für die benutzten elektrischen Pegel durchgesetzt. Die hier definierten elektrischen Pegel bestehen aus 2 Leitungen. CAN-High und Can-Low enthalten das invertierte und das nicht invertierte serielle Datensignal. Man spricht hier auch von einem differentiellen Signal.
Durch die redundant invertierte Übertragung der logischen Signale auf einer zweiten Leitung wird eine hohe Störsicherheit erreicht. In die Leitung eingestreute Störungen wirken auf beide Leitungen in der gleichen Richtung. Da die beiden differentiellen Leitungen jedoch immer invertierte Pegel haben, kann nur eine der beiden, niemals jedoch beide gleichzeitig in entgegengesetzten Richtungen gestört werden. Man spricht hier auch von Gleichtaktunterdrückung, auf englisch CMRR - Common Mode Rejection Ratio welche in dB angegeben wird. Das folgende Bild stellt beide CAN Leitungen bei 125kbaud mit Störungen dar. Während das untere Signal durch die eingestreuten Störungen den Low Pegel bereits deutlich nach oben überschreitet, besteht noch keinerlei Gefahr wenn man den Abstand als Differenz zum oberen Signal und nicht auf Masse bezogen betrachtet.
Bild hier
Durch die Ausführung als offener Collector (PNP auf GND bei CAN-L und NPN auf VCC bei CAN-H) können ausserdem mehrere Teilnehmer auf dem Bus parallelgeschaltet werden, ohne daß im Konfliktfall elektrische Kurzschlüsse entstehen. Die High/Low Grenzen der Pegel sind bei CAN mit 1,5 und 3,5 Volt definiert.
<table border="1"><tr><td>TTL Pegel</td><td>CAN Pegel</td><td>plusschaltende PNP Leitung (CAN-H)</td><td>nullschaltende NPN Leitung (CAN-L)</td><td>differentielle Spannung zwischen CAN-H und CAN-L</td></tr><tr><td>Low</td><td>dominant</td><td>Transistor ist geoeffnet</td><td>Transistor ist gegen Masse geschlossen</td><td>minus 5 Volt</td></tr><tr><td>High</td><td>recessive</td><td>Transistor ist gegen Plus geschlossen</td><td>Transistor ist geöffnet</td><td>plus 5 Volt</td></tr><tr><td>Tristate</td><td>floating</td><td>Transistor st geöffnet</td><td>Transistor ist geöffnet</td><td>0 Volt</td></tr></table>
Als Treiberschaltkreis ist der PC 82C250 oder 251 von Phillips in weiten Bereichen gebräuchlich. Einige Prozessoren (z.Bsp. MC68705X32) haben bereits integrierte Treiber, sind dafür aber nicht kurzschlussfest. Die Signale haben normalen 5 Volt TTL Pegel, sind jedoch in 24 Volt Systemen kurzschlußfest. Bei CAN Signalen spricht man dann aber nicht mehr von High und Low, sondern von Dominant und Recessive Pegel.
Steckerbelegung
Hier hat sich der von CiA vorgeschlagene 9 polige D Stecker weitgehend durchgesetzt. Um das Bussystem weiterschleifen zu können, sind sowohl weibliche wie auch männliche Steckverbinder gleichzeitig im Einsatz. Leider ist hier auch eine Verwechslungsmöglichkeit mit V24 Leitungen vom PC möglich.
Für die Übertragung von CAN Signalen ist mindestens ein 3 poliges Kabel mit CAN-High, CAN-Low und Ground erforderlich. CiA definierte daneben auch noch einen 5 poligen Rundsteckverbinder und einen "open style" Stecker, ohne aber auf die Abmessungen einzugehen. Den open-style Stecker gibt es 4 oder 5 polig. Er sieht im CiA Bild so ähnlich wie etwa die Phönix MSTB Reihe aus. Mit anderen Worten, wer keinen 9 poligen D Stecker nehmen möchte, kann auch machen was er will und trotzdem CAN kompatibel draufschreiben.
Eine ebenfalls nützliche Sache ist der von CiA definierte 10 polige "multipole Connector". Dahinter steckt eine 10 polige Doppelpfostenleiste. Die Belegung erhält man automatisch wenn man einen 9 poligen Min-D Stecker mit Flachbandkabel verpresst. Pin 10 ist dabei reserviert und bleibt frei. (Zigzag Zählweise beachten)
<table border="1"><tr><td>Pin</td><td>Signal</td><td>Beschreibung</td></tr><tr><td>1</td><td>-</td><td>reserviert</td></tr><tr><td>2</td><td>CAN_L</td><td>dominant low</td></tr><tr><td>3</td><td>CAN_GND</td><td>Masse</td></tr><tr><td>4</td><td>-</td><td>reserviert</td></tr><tr><td>5</td><td>CAN_SHLD</td><td>optional</td></tr><tr><td>6</td><td>GND</td><td>optional</td></tr><tr><td>7</td><td>CAN_H</td><td>dominant high</td></tr><tr><td>8</td><td>-</td><td>reserviert</td></tr><tr><td>9</td><td>CAN_V+</td><td>24 Volt Betriebsspannung</td></tr></table>
Für eine Datenübertragung werden mindestens Pin 2, Pin 7 sowie eine Masse benötigt. Bei höheren Datenübertragungen und langen Leitungen bis 1 Mbit kann zur Vermeidung von Reflexionen ein verdrilltes Kabel eingesetzt werden. Spezielle Buskabel (kreuzkrabbensackteuer) gibt es zum Beispiel bei Lapp unter der Bezeichnung Unitronic® Bus LD 2x2x0,22. Die Farben sind auch genormt, wenngleich es hier auch noch unterschiedliche Firmennormen gibt. Grün-Gelb und Weiß Braun ist nach DIN jeweils ein Leitungspaar. Welches Paar für CAN_H und CAN_L benutzt wird kann sich aber wieder jeder selber raussuchen. Auch nicht gepaart verdrillte Kabel benutzen die gleichen Farbcodes. Hier isoliert man vorsichtig ab und zähle die Einzeladern in der Lage wie sie aus dem Mantel rauskommen. Bei paarverseilten Kabeln bietet sich die Nutzung der zweiten Masse auf Pin 6 für die beiden Leitungspaare an.
Busterminierung
Die Busterminierung erfolgt beim CAN Bus in der Regel mit 120 Ohm. Eine Terminierung ist auch schon bei kurzen Leitungen mit niedrigen Baudraten zwingend erforderlich, da sie bei CAN gleichzeitig als kombinierter Pullup und Pulldown Widerstand für alle Teilnehmer arbeitet. Ohne Terminierung gibt es nicht nur Reflexionen, sondern beide CAN Leitungen hängen in der Luft. Dabei funktioniert auch bei kurzen Leitungen garantiert überhaupt nichts. In der Praxis reicht bei kurzen Leitungen eine Terminierung an einem Ende, idealerweise wird der Bus aber an beiden Enden (und nur dort) mit jeweils 120 Ohm terminiert. Im Gegensatz zu einer Ethernet Koaxleitung welche mit Manchestercodierung arbeitet, sorgt der Terminierungswiderstand im CAN Bus überhaupt erst dafür, daß ein Strom im Schnittstellenkabel fließt.
Eine Abschirmung ist auf Pin 5 optional. Ebenso ist die Betriebsspannung auf Pin 9 optional. Diese wird von vielen Herstellern (wegen Angst vor Kurzschluss?) nicht unterstützt, ist aber zur einfachen Versorgung von externen Tranceivern, Schnittstellenkonvertern, Debughilfsmittel u.a. recht praktisch und hilfreich.
Telegrammaufbau
Das Bild zeigt ein komplettes CAN Telegram. Der Sender versucht ein 1 Byte langes Telegramm mit den Nutzdaten = FF an den Empfänger mit dem Identifier 000 in der Geschwindigkeit von 125 kBaud zu verschicken. Es handelt sich hier um einen sogenannten Data Frame. Demgegenüber gibt es bei CAN auch Remote, Error und Overload Frames, auf welche in der Praxis jedoch auch gut verzichtet werden kann.
Der im Bild angesprochene Partner antwortet jedoch im Acknowledge Slot offensichtlich nicht, was im Bild aber nur durch die Wiederholung des Telegramms nach 230 uS vermutet werden kann. Eine derartige Wiederholstrategie gehört zu den Hardwareaufgaben einer CAN Schnittstelle und funktioniert ohne weitere Aktivitäten der Software.
Bild hier
Ein CAN Telegramm ist am Oszilloskopbild relativ schwer zu interpretieren, da CAN die sogenannte Bit-Stuffing Technik benutzt. Diese Technik sorgt ähnlich wie die Manchester Codierung bei Ethernet Koax dafür, daß auf der Datenleitung auch bei konstanten Datenmustern wie 00 00... oder FF FF ... immer eine Wechselspannung mit Flanken ist. An diesen Flanken kann sich die Gegenstelle aufsynchronisieren und die Übertragungssicherheit wird erhöht. Außerdem können Wechselspannungen im Gegensatz zu Gleichspannungen mit Trafos problemlos galvanisch getrennt werden. Die Schnittstellenhardware von CAN sorgt dafür, daß nach einem Nibble gleichbleibender Daten ein entgegengesetzt liegendes Bit in den Datenstrom eingebaut wird.
Nach dem Startbit in der ersten fallenden Flanke folgt der Identifier als Adresse des angesprochenen Zielteilnehmers. Durch die nach jedem Nibble "eingestopften" Einsen sind die 3 Nullen des Identifiers gut zu erkennen. Danach folgt eine Reihe von Steuerbits, alsda wären
- RTR - Remote Transmission Request, ist bei Datentelegrammen immer 1.
- R0, R1 - 2 reservierte Bits, bei CAN Rev. 2.0 liegt hier das IDE zur Kennzeichung Extended Identifier
- DLC3..0 - Data Length Code welcher angibt wieviele Bytes Nutzdaten folgen, Wertebereich 0 ... 8
Danach folgen die Nutzdaten, im vorliegenden Fall ein einziges Byte mit dem Inhalt FF. Auch hier ist das Byte durch das eingestopfte Bit (hier eine Null) beginnend im dritten Kästchen gut zu erkennen. Abschliessend folgt die Prüfsumme in einem CRC Feld sowie das CRC Delimiter Bit welches immer Recessive ist.
Bild hier
Beim letzten Low Impuls am nicht gestrichelten Cursor handelt es sich um 2 Bits, dem sogenannten "Acknowledge Slot". Der sendende Teil liest seine eigenen Telegramme immer zurück und prüft, ob der Empfänger diesen Acknowledge Slot mit dominantem Pegel für korrekt empfangene Telegramme ausfüllt. Auf diese Weise kann der Absender immer feststellen, ob ein angesprochener Empfänger das Telegramm auch erhalten hat, oder ob es wiederholt werden soll. Deshalb nochmals das gleiche Telegrammbild für den Fall eines erfolgreich empfangenen und bestätigten Telegramms. Auf Kanal 1 ist die Sendeleitung des angesprochenen Empfängers und auf Kanal 2 die Empfangsleitung dargestellt. Die Übertragung von einem einzelnen Byte bei 125 kbaud dauert 80uS was natürlich einen Haufen Zeitverschwendung darstellt. Bei mehreren Bytes Datenmenge sinkt der durch das Protokoll verursachte Overhead jedoch drastisch ab.
Bit Stuffing, CRC und Wiederholstrategien sind Hardwaremerkmale der CAN Schnittstelle, so daß sich hier die Software zum gesicherten Datenaustausch bereits erheblich vereinfacht.
Details zum Telegrammaufbau kann man auch in der Originaldokumentation von Bosch nachlesen. Im Gegensatz zu den CiA Dokumenten liest sich die Terminologie kompakt und verständlich, ist außerdem kostenlos verfügbar. Darüber hinaus braucht man nur die Hälfte zu lesen weil die zweite Hälfte das Gleiche mit langen Identifiern beschreibt.
Teilnehmeradressierung
Beim CAN Bus kann im Prinzip jeder Teilnehmer mit jedem anderen kommunizieren und jeder darf im Prinzip auch Daten ohne besondere Aufforderung irgend eines Masters verschicken. Wie bei Ethernet kann es auch hier zu Kollisionen kommen, die allerdings per Hardware aufgelöst und durch Wiederholung behoben werden. Eine Kollision wird dadurch erkannt, daß ein Sender den gesendeten Identifier selbst zurückliest und vergleicht. Bei Ungleichheit war ein Teilnehmer mit höherer Priorität da, welcher die Leitung an irgendeiner Stelle in den dominanten Pegel gezogen hat.
Die Identifier können als Adresse des Busteilnehmers verstanden werden. Andererseits kann der Identifier auch als Bedeutung der nachfolgenden Daten verstanden werden, so daß der Empfänger hiermit entscheidet ob die Daten für ihn überhaupt interessant sind. CAN1.0 und CanOpen arbeitet mit 11 bit Identifierlänge, CAN2.0 oder auch Full Can arbeitet mit den erweiterten 29 bit Identifier. Beide Formate sind auch auf einem Bus untereinander kompatibel und können beliebig vermischt werden. Sinn und Zweck ist nicht gerade eine Adressierung von derart vielen Teilnehmern, sondern vielmehr können ja auch Telegramme mit 0 Nutzdatenbytes verschickt werden. Ein möglicher Empfänger erkennt dabei bereits durch die Tatsache des Eintreffens eines Telegramms (per Hardware) am Identifier um welchen "Befehl" der Anwendungsschicht es sich handelt. In diesem verkürzten Wege müssen von der Anwendungssoftware keinerlei Nutzdatenbytes ausgewertet werden.
Bild hier
Außerdem ergibt sich die Möglichkeit von Multicasting. Das heißt ein von einem Sender einmal verschicktes Telegramm wird von mehreren Teilnehmern gleichzeitig empfangen und ausgewertet. Hier fällt es jedoch in der Hardware Wiederholstrategie nicht mehr auf, wenn ein einzelner Empfänger ausfällt. Mindestens ein Empfänger muß jedoch den Acknowledge Slot in dominanten Pegel bringen. Eine gesicherte Multicast Übertragung muß deshalb in der Software erfolgen, weil nur diese auch wissen kann an wieviel und welche Teilnehmer das Telegramm gerichtet ist. Das vorstehende Bild zeigt wiederum Sendeleitung (Kanal1) und Empfangsleitung (Kanal2) eines CAN Teilnehmers. Er empfängt hier ein 8 Byte Telegramm welches er nach dem CAN-Open "multiplex domain download protocoll" mit einem weiteren 8 Byte Telegramm bestätigt. Das erste eingegangene Telegramm wird mit einem Acknowledge Slot per Hardware bestätigt. Danach vergehen circa 4 msec welches die Software zur Telegrammdekodierung und Ausführung benötigt. (Hier ein Bildschirm-Löschbefehl). Danach wird ein Telegramm welches ebenfalls 8 Nutzdatenbytes enthält zurückgeschickt.
Zu beachten: Das selbst gesendete Telegramm erscheint über die Bustreiber Hardware zwangsläufig auch automatisch auf der Empfangsleitung.
Telegrammfilterung
Im Prinzip kann jeder an das CAN Bussystem angeschlossene Teilnehmer alle auf dem Bus laufenden Telegramme mithören. Ist er dabei als Zielteilnehmer aber überhaupt nicht gefragt, erkennt er dies an einer unpassenden Identifieradresse und verwirft das Telegramm ohne zu antworten oder eine andere Aktion in der Anwendung zu veranlassen. Um die Rechenzeit der Software für diese Entscheidung bei hohem Telegrammaufkommen fremder Teilnehmer nicht zu belasten, haben die gängigen CAN Controller hier eine Filterhardware vorgesehen. Diese Filterhardware kann per Software eingestellt werden und erzeugt nur bei eingehenden Telegrammen mit dem gewünschten Identifier einen Softwareinterrupt.
Telegramme mit fremden Identifiern werden somit von der Software überhaupt nicht bemerkt und benötigen keine Rechenzeit. Mit Wildcard Funktionen in den Registersätzen können auch Identifierbereiche eingestellt werden in welchen ein bestimmter Busteilnehmer reagiert. Derartige Busfähigkeiten sind auch unter den Begriffen "Message Routing" und "Data Validation" bekannt.
CAN Open
Im Prinzip genügt die vorstehende Information jetzt um 2 Produkte zu basteln die über CAN Nachrichten austauschen. Robert Bosch definiert in seiner Spezifikation aber absichtlich keine physikalische Anbindung, so daß jeder Entwickler von Produkten hoher Stückzahl seine Anwendung optimieren kann. Ebenso gibt es bei Bosch keine Vorschläge über den Inhalt der übertragenen Daten (Application Layer). Um CAN Produkte unterschiedlicher Hersteller kompatibel zu machen (das Märchen vom Computer), hat sich eine Gruppe von Herstellern mit dem Namen Can in Automation (CiA) zu einem Verein zusammengeschlossen.
CiA betreibt eine nette Webseite mit viel hübschen Bildern die gut sind, wenn man sowieso schon weiß wie CAN funktioniert. Im Endeffekt erfährt man dann aber auf dieser Seite nur gegen eine deftige gebührenpflichtige Mitgliedschaft wie das CAN Open Protokoll dann wirklich aussieht. Darüber hinaus kann man auch wieder 90% der relativ bürokratischen CiA Definitionen vergessen. Tatsächlich sieht es auch so aus, daß kaum ein Hersteller die komplette mögliche CiA Spezifikation irgendwo implementiert hat, da die Anwendungen bereits mit minimalen Funktionen laufen und sowieso niemand Interesse daran hat, durch einen eventuell etwas billigeren Mitbewerber ersetzt werden zu können.
Eine wichtige Doku von CAN-Open ist der Draft Standard DS301. Aber auch von diesem umfangreichen Dokument werden nur wenige Seiten benötigt, um erfolgreich ein Protokoll zu programmieren welches mit CAN-Open Geräten kommuniziert. Andere CiA Normungsdokumente beschäftigen sich entweders mit der physikalischen Schnittstelle (diese sind frei zugänglich) oder sie beschreiben Geräteprofile für bestimmte Geräteklassen. So zum Beispiel der Draft Standard DS403 für Mensch-Maschine-Interfaces (MMI). Jeder der ein Terminal (MMI) baut, kann sich dann heraussuchen welche Features er davon implementiert. In der Praxis sieht es so aus, daß ein Gerätehersteller dann wiederum eine Beschreibung für die implementierten Teile der Funktionen hat um dem Anwender überhaupt einen Einsatz seines Gerätes zu ermöglichen. Obwohl eine einzige Art im angesprochenen Gerät ein Bit zu schalten völlig ausreichen würde, definiert CiA immer gleich einen ganzen Haufen davon, von welchen dann meist nur eines benutzt wird . Dagegen hinaus fehlen typischerweise viele wichtige Funktionen (wie zum Beispiel die komplette Grafikfähigkeit bei MMI´s) die dann in den "manufacturere specific" Objekten untergebracht werden muß. Das ist dann so, als ob man es gleich ohne Can-Open Kompabilität macht.
Deshalb hier noch eine Übersicht über die wichtigsten Details des DS301 Standards. Die in Autos eingesetzten Dateninhalte der Anwendungsschicht basieren übrigens nicht auf CiA sondern auf dem Keyword 2000 Protokoll.
Objektorientiertes Konzept
CiA definiert den Datenaustausch mit sogenannten Objekten. Diese sind in einem "Objekt Dictionary" für ein bestimmtes Gerät beschrieben. Die 16 Bit Objektnummer welche in jedem Telegramm übergeben wird, zeigt der Gegenstelle an, welche Funktion die im Telegramm enthaltenen Daten auslösen sollen. Die Objektnummer wird mit einem 8 bit Subindex, in der CiA Terminologie auch "Multiplexor" genannt, erweitert. Die Objektnummern können also so ähnlich wie die Identifier oder eine Erweiterung von diesen verstanden werden. Der Unterschied ist nur, daß Identifier von der Hardware verarbeitet werden können, während Objektnummern von der Software verarbeitet werden müssen.
Can Open unterscheidet die Datenübertragung zwischen PDO und SDO Objekten. Bei PDO´s handelt es sich um sogenannte Prozess Daten Objekte. Dies ist so in etwa die Art und Weise wie man einem Kommunikationspartner im einfachsten Fall etwas schicken würde wenn man 2 CAN Geräte entwickelt und noch nie etwas von CanOpen gehört hat. Mit PDO´s kann jeder Busteilnehmer irgend etwas an einen anderen verschicken. Die Bestätigung erfolgt nur mit dem CAN Hardwaremechanismus und die Telegrammlänge ist entsprechend der CAN Schnittstellenhardware auf 8 Bytes beschränkt.
Bei SDO´s handelt es sich um sogenannte Service Daten Objekte. Warum diese auch immer so heißen, die Terminologie bei CAN Open ist leider durchweg meistens unverständlich. Dahinter versteckt sich jedoch ein Übertragungsprotokoll, an welcher die angesprochene Gegenstelle mit einem Rücktelegramm zur Bestätigung antwortet. Die Verwendung des Begriffs "Protokoll" ist mir in diesem Zusammenhang jedoch auch nicht klar denn CiA bezeichnet viele Details eben als solches Protokoll obwohl es gar nicht eigenständig funktioniert. Mit SDO können jedenfalls Daten an ein Gerät geschickt werden, deren Erhalt und Verarbeitung im Zielgerät dann zusätzlich mit einem per Software zurückgeschickten Telegramm bestätigt werden. CiA nennt dies "SDO Domain Download".
Durch das Rücktelegramm können auf diese Weise auch Daten von einem Gerät gezielt angefordert werden was dann "SDO Domain Upload" genannt wird. Eine spezielle Variante dieser SDO Protokolle erlaubt auch einen segmentierten Betrieb zum Austausch längerer Datenketten wie sie in einem Telegramm Platz haben. Um die Verwirrung mit den Begriffen komplett zu machen, bezeichnet CiA eine Zustellung von kleinen Datenmengen die in ein einzelnes Telegramm passen als "expedited" und die längeren Datenmengen mit mehreren Telegrammen als "normal" oder auch als "segmented".
Beispiel Trace
Diese Beispielaufzeichung dokumentiert den Datenaustausch nach CanOpen in den hauptsächlichen Betriebsarten. Es gibt daneben noch fast beliebig viele weitere Protokolldienste wie etwa zum dynamischen Zuordnen von Netzadressen (NMT Dienste) oder dem dynamischen Mapping von Objekten (zu was auch immer das gut sein soll) welche aber in der Praxis leicht verzichtbar sind.
Bild hier
Die zweite Spalte des Trace enthält den mit den Telegrammen übertragenen 12 Bit Identifier. Es handelt sich hier um eine Kommunikation mit einem CanOpen. Gerät welches auf die "Node # 64" (dezimal) eingestellt ist. Daraus berechnen sich die tatsächlich in der Übertragung verwendeten Identifier wie später beschrieben.
Es ist zunächst auffällig, daß es kürzere und längere Telegramme mit bis zu 8 Datenbytes gibt. Bei den kurzen Telegrammen handelt es sich um PDO´s, welche nach CanOpen auf einem eigenen Identifier verschickt werden. Die in PDO´s folgenden Bytes sind Nutzdatenbytes ohne irgend welchen Ballast durch das Protokoll.
Beim ersten und zweiten Telegramm meldet das Gerät, daß ein Impuls am Bit 6 des Eingangs von Byte 1 aufgetreten ist. Das erste Telegramm entspricht der steigenden Flanke, das zweite Telegramm der fallenden Flanke. Die Analyse des Identifiers $1C0 ergibt, daß es sich um ein CanOpen Gerät mit dem Node ID 64 handelt, welches einen Write PDO Nr. 1 verschickt. Dieser PDO kann ohne weitere Bestätigung auch von mehreren Busteilnehmern gleichzeitig ausgwertet werden.
Beim Dritten Telegramm wird das Can Open Gerät mit dem Node ID 64 durch einen Read PDO Nr. 1 dazu aufgefordert, zum Beispiel einen Ausgang zu setzen. Über die Bedeutung der einzelnen Nutzdaten in den PDO Telegramm müssen die Kommunikationspartner untereinander klar sein. Normalerweise handelt es sich hier um eine direkte Kopie der Ein und Ausgangsports der beteiligten Geräte. PDO´s haben keinen Protokolloverhead und es werden auch nur die tatsächlich benötigten Datenbytes übertragen. Genügen die vorhandenen 8 Datenbytes nicht, können nach CAN Open weitere PDO´s (2,3,4) mit abweichenden Offsets im Identifier benutzt werden.
Bei allen 8 Byte Telegrammen handelt es sich im Bild um SDO´s. Auch PDO können natürlich 8 Bytes enthalten, diese sind jedoch immer über den Identifierbereich als solche zu identifizieren. Man sieht hier schon, daß die Identifier bei CAN-Open eigentlich als Dateninhalt übertragen werden. Durch die weite Zerstreutheit kann dabei leider meistens von den Hardwarefiltern der Schnittstellenbausteine kein Gebrauch mehr gemacht werden. Bei hohen Busbelastungen in zeitkritischen Anwendungen empfiehlt sich daher ein Abweichen von den CiA Identifiern. Trotzdem kann über den gleichen Bus natürlich auch parallel ein CanOpen Verkehr ablaufen solange die Identifier so gewählt werden daß sie sich nicht in die Quere kommen.
Die dritte Spalte der SDO´s enthält mit dem ersten Datenbyte im Telegramm den sogenannten Command Specifier (CSS) oder auch das Kommandobyte von CanOpen welches über die Telegrammart Auskunft gibt. Dies ist ein relativ chaotisch aufgebautes Byte mit viel Bitgepopel welches über die Datenrichtung (upload/download) sowie die Datenmenge informiert.
Im dritten Telegramm mit dem Kommando Byte 23 wird auf ID 640 das Gerät mit Node 64 (dez) über ein SDO angesprochen. Wie aus den Spalten 2 und 3 leicht ersichtlich ist, handelt es sich hierbei um das Objekt $ 2000 mit dem Subindex 00 (Spalte 4). Intel "little endian" Darstellung mit verdrehten Low und Highbytes beachten. Die verbleibenden 4 Datenbytes enthalten Nutzdaten welche jedoch mit 0 aufgefüllt sind. Auch hier müssen sich die Kommunikationspartner über die Bedeutung von Objekt 2000 im Klaren sein. Es handelt sich hier um ein Clearscreen Kommando, was aber weder aus dem Trace noch aus CiA hervorgehen kann. Etwa hundert ms später wird mit dem Kommandobyte $60 ein Telegramm zurückgeschickt, welches das erfolgreiche Löschen des Bildschirms bestätigt.
Daraufhin wird noch zweimal ein SDO, diesmal mit dem Objekt 2010 verschickt. Im ersten Fall erfolgt eine negative Quittierung durch das Kommandobyte mit dem Inhalt 80. Die Datenbytes in der Quittierung geben dabei an, daß das Objekt nicht ausgeführt wurde weil es sich um eine Überschreitung des Wertebereichs handelt. Eine solch negative Quittierung ist in CiA bei "Abort SDO Transfer Protokoll" nachzulesen. Bei Objekt 2010 handelt es sich im Beispiel um ein Einstellen des Cursors, welches dann mit anderen Daten nochmals versucht wird. Wie die Antwort mit dem Kommandobyte 60 zeigt, diesmal erfolgreich.
Das in der Bildmitte verschickte 3 Byte PDO Telegramm wurde aus Gründen der Übersichtlichkeit eingefügt. Hier wird der Ausgang in Gerät mit Node 64 wieder zurückgesetzt, welcher in Telegramm 3 eingeschaltet wurde.
Bei der darauffolgenden Sequenz handelt es sich um eine segmentierte Übertragung. Bei der segmentierten Übertragung handelt es sich eigentlich um eine Zustandsmaschine die in einer vorgegebenen Weise ablaufen muß und nicht durch andere Telegramme unterbrochen werden darf. Das Kommandobyte 20 leitet die segmentierte Übertragung von Objekt 2800 ein. Der Subindex steht auf FF und das darauffolgende Byte 0f besagt, daß 15 Nutzbytes übertragen werden sollen. Dieses Telegramm dient zum Einleiten einer segmentierten Übertragung und ist bei CiA unter "Initiate SDO Download Protocol" beschrieben. Es erfolgt eine positive Bestätigung mit dem Kommandobyte 60 sowie ein weiterer SDO mit Kommandobyte 00 welcher auch die ersten 7 Byte Nutzdaten enthält. Diese und folgenden SDO´s sind in CiA jedoch wieder unter dem "Download SDO Segment Protocol" beschrieben obwohl es sich hier um einen nicht unterbrechbaren Vorgang (geschweige denn um ein anderes "Protokoll") handelt. Dieses Telegramm wird mit dem Kommandobyte 20 positiv bestätigt und mit dem Kommandobyte 10 weitere 7 Byte Nutzdaten verschickt. Das Kommandobyte ist gegenüber den ersten 7 Byte Portion anders, weil hier ein Toggle Bit den fortschreitenden Download kontrollieren soll. Ebenso ist in der positiven Antwort mit Kommandobyte 30 dieses Toggle Bit gesetzt. Im letzten Telegramm muß nur noch ein Nutzbyte übertragen werden. Im Kommandobyte 0D ist das Toggle Bit wieder zurückgesetzt, dafür ist das Bit c gesetzt, welches besagt, daß keine weiteren Segmente folgen. Außerdem ist darin an den Bitpositionen 3,2 und 1 die Anzahl der im Telegramm gültigen Nutzbytes noch codiert.
Nach einem weiteren PDO erfolgt noch ein abschliessender SDO im "expedited" Modus welcher ohne Segmentierung Nutzdaten bis zu 4 Bytes übertragen kann. Interessant ist hierbei die Tatsache, daß es sich auch hier um Objekt 2800 handelt, eben dieses Objekt welches zuvor in segmentierter Weise übertragen wurde. Das sementierte Protokoll kann selbstverständlich auch Nutzdaten <5 Bytes übertragen, allerdings ist hier der Protokollballast relativ hoch. Dies ist auch einer der Schwachpunkte des CAN Open Objektkonzepts. Ein neu eingeführtes Objekt muß eigentlich zwei mal implementiert werden. Einmal für das segmentierte und einmal für das "expedited" Übertragungsprotokoll. Natürlich funktioniert es auch nur mit einer Protokollart, man muß sich jedoch darauf verlassen, daß die Gegenstelle auch nur diese benutzt. Dies ist eine der gemeinen Unkompabilitäten zwischen CanOpen Produkten oder auch die Einleitung zum Märchen von den benutzerfreundlichen Systemen. (Hätten sie alles bei uns gekauft...)
Beim letzten SDO ist auch noch interessant, daß das Kommandobyte 2B anstelle 23 bei den vorhergehenden SDO´s ist. An Bit 3 und 2 ist eine Längeninformation codiert, die besagt, daß nur 2 Bytes des Telegramms verwendet werden. Die Nutzdatenbytes 32 und 33 werden im Empfänger verworfen.
CANOpen Identifier
CiA schlägt die Verwendung bestimmter Identifierbereiche für bestimmte Funktionsklassen vor. Der 11 bit CAN Identifier wird nach CAN-Open in eine 8 bit Node-ID umgerechnet und umgekehrt. Einige Adressbereiche haben spezielle Bedeutung. Dummerweise liegen die in CAN-Open definierten Identifierbereiche mit speziellen Systemfunktionen so ungeschickt, daß die Eingangsfilter der gebräuchlichen Kontroller normalerweise nicht so eingestellt werden können, daß die Hardware alle nichtrelevanten Telegramme ausfiltert.
Die in der Tabelle zweite Hälfte stehenden Spezial ID Bereiche sind hier nicht näher beschrieben. Möchte man sich eigene Identifier ausdenken, ist es jedoch nützlich dies zu vermeiden um einen gleichezeitigen Datenverkehr von CanOpen Geräten nicht zu behindern.
Can Open erlaubt logische Gerätenummern (Nodes) von 1 bis 127 (dezimal). Dieser Bereich entspricht dem genannten ID Bereich mit dem jeweils entsprechenden Offset.
<table border="2"><tr><td>Telegrammart</td><td>Offset (dezimal)</td><td>ID Bereich dezimal </td>>td>ID Bereich hexadezimal </td></tr><tr><td>PDO1 (tx)</td><td>384</td><td>385-511</td><td>181-1ff </td></tr><tr><td>PDO1 (rx)</td><td>512</td><td>513-639</td><td>201-27f</td></tr><tr><td>PDO2 (tx)</td><td>640</td><td>641-767</td><td>281-2ff</td></tr><tr><td>PDO2 (rx)</td><td>769</td><td>769-895</td><td>301-37f</td></tr><tr><td>PDO3 (tx)</td><td>896</td><td>897-023</td><td>381-3ff</td></tr><tr><td>PDO3 (rx)</td><td>1024</td><td>1025-1151</td><td>401-47f</td></tr><tr><td>PDO4 (tx)</td><td>1152</td><td>1153-1279</td><td>481-4ff</td></tr><tr><td>PDO4 (rx)</td><td>1280</td><td>1281-1407</td><td>501-57f</td></tr><tr><td>SDO (tx)</td><td>1408</td><td>1409-1535</td><td>581-5ff</td></tr><tr><td>SDI (rx)</td><td>1536</td><td>1537-1663</td><td>601-67f</td></tr><tr><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Netzmanagement</td><td>*</td><td>0</td><td>0</td></tr><tr><td>Synchronisation</td><td>*</td><td>128</td><td>80</td></tr><tr><td>Zeitstempel</td><td>*</td><td>256</td><td>100</td></tr><tr><td>Notaus</td><td>128</td><td>129-255</td><td>81-ff</td></tr><tr><td>Netzfehler</td><td>1792</td><td>1793-1919</td><td>701-77f</td></tr></table>
* CanOpen Spezial - ID ist unabhängig von der eingestellten Can Open Gerätenummer
Download SDO Segment Protocol
Hier versteckt sich die segmentierte Übertragung von längeren Datenmengen. Die segmentierte Übertragung muß zunächst durch ein "Initiate SDO Download" Telegramm mit gelöschtem e-Bit eingeleitet werden. (siehe vorheriges Kapitel). Danach folgt ein Telegramm mit den folgenden Inhalten:
Byte 1
Bit 7,6,5 (css = client command specifier) ist hier 000
Bit 4 (t=toggle bit) Im ersten verschickten Segment ist das Toggle Bit = 0, in jedem folgenden Segment muß es invertiert werden.
Bit 3,2,1 enthält die Anzahl der in diesem Telegramm ungültigen Nutzbytes. Wertebereich ist 0 bis 7. Bei 7 ungültigen Nutzbytes wäre das ein segmentiertes Telegramm ohne Nutzdaten was natürlich keinen Sinn macht.
Bit 0 (c=continous Bit) 0 zeigt an, daß noch weitere Telegrammsegmente folgen, 1 kennzeichnet das letzte Telegramm
Byte 2 bis 8
enthalten bis zu 7 Nutzdatenbytes von einem Segment.
Die positive Bestätigung erfolgt mit einem Telegramm wo im Kommandobyte 1 das Bit 7,6,5 (SCS server command specifier) = 1 ist und das Toggle Bit an Bit 4 unverändert zurückgegeben wird. Alle restlichen Bits sowie alle anderen 7 Bytes des positiven Bestätigungstelegramms sind 0. Im Fehlerfall wird ein Telegramm entsprechend dem "Abort Transfer Protokoll" zurückgegeben.
Das "Upload SDO Segment Protocol" ist gleichartig aufgebaut, mit dem Unterschied daß ccs=3 und scs=0 ist.
Abort SDO Transfer Protocol
Hier versteckt sich die Art und Weise wie ein SDO Telegramm im Fehlerfall beantwortet wird. Während in den letzten beiden Abschnitten die einzelnen Bits teilweise mehrfach belegt sind (unions), wird hier zwischen 29 möglichen Fehlerursachen unterschieden. Diese 29 Fehlerursachen sind sage und schreibe in einem 32 bit Langwort codiert. Dies unterstreicht wiederum den fehlenden Praxisbezug von Normungskremien.
Viele Köche verderben den Brei und es gibt deshalb auch Fehlermeldungen wie zum Beispiel 0604 0047 hex, was im Klartext soviel wie: "Allgemeine interne Inkompabilität im Gerät" bedeutet. Demgegenüber wird natürlich gegenüber einem Fehler wie "Allgemeine Parameterinkompabilität" unterschieden und man kann sich des Eindrucks nicht verwehren als ob die CiA Mannschaft ganz gut bei Micro$oft hätte anfangen können wo diese Meldungen bei Windows Benutzern zwischen "Allgemeinem Fehler" und "Allgemeiner Schutzverletzung" ganz gut und unauffällig augehoben wären. Solange können sich die Anwender jedoch selber raussuchen warum irgendetwas gerade nicht funktioniert.
Open Source
Wen es jetzt immer noch näher interessiert oder wer keine Lust zum Schreiben einer eigenen Software hat, kann bei Vector einen in C geschriebenen Sourcecode kaufen. Wer als Bastler kein Geld hat und sowieso einen kompakteren und schnelleren Code braucht als er vom C Compiler abgesetzt wird, kann hier einen CanOpen Source Code mit allen vorher beschriebenen Features kostenlos runterladen . Der Code wurde Assembler geschrieben und auf einem Motorola 68HC908 AT60 Prozessor getestet. Er läßt sich leicht an andere Peripheriegeräte und eigene Bedürfnisse anpassen.
Artikel bereitgestellt von Jürgen V. www.janvi.de
Zitieren
Lesezeichen