CAN

Alle 1000 Tricks f�r Hobbybastler auf einen Blick

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.

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.

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)

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.

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.

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.

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.

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.

* CanOpen Spezial - ID ist unabh�ngig von der eingestellten Can Open Ger�tenummer

Initiate SDO download Protocol

Hier versteckt sich der Aufbau der SDO Telegramme

Byte 1 (Kommandobyte)

• Bit 7,6,5 (ccs = client command specifier), Wert 001 f�r "initiate download request"
• Bit 4 unbenutzt immer 0
• Bit 3 und 2 enth�lt die Anzahl der nicht benutzten Datenbytes im Telegramm (0 bis 3) wenn Bit 0 gesetzt
• Bit 1 (e) 1= Einzelelegramm (expedited) Transfer, 0 = segmentierter Transfer
• Bit 0 (s) 1 = L�ngenangabe in Bit 3+2 g�ltig, 0= L�ngenangabe ung�ltig

Byte 2+3

• Enth�lt die Objektnummer in Lowbyte - Highbyte Folge (Little Endian Darstellung nach Intel)

Byte 4

• Subindex

Byte 5 bis 8

• Nutzdaten (ebenfalls in Intel Darstellung)

Die positive Best�tigung des Telegramms erfolgt in einem Telegramm wo im Kommandobyte 1 das Bit 7,6,5 (SCS server command specifier) = 3 ist. Index und Subindex in den Bytes 2,3 und 4 werden zur�ckgegeben, der Rest des positiven Best�tigungstelegramms ist mit 0 reserviert. Im Fehlerfall wird ein Telegramm entsprechend dem "Abort Transfer Protokoll" zur�ckgegeben.

Das "Initiate SDO Upload" Protokoll ist in Gegenrichtung gleichartig aufgebaut, mit dem Unterschied da� scs=2 und ccs=2 ist.

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.

� J.V. 2000

home