Siehe auch: Übersicht CAN-Tester
Der CAN-Tester ist als Testprogramm auf niedriger CAN-Bus-Telegramm-Ebene konzipiert, mit einigen Erweiterungen die für "hausinterne Tests" bei Firma MKT verwendet werden. Möglich sind:
Der CAN-Tester kann dabei sowohl als Client oder Server arbeiten. Um eine sinnvolle SDO-Server-Funktionalität zu ermöglichen, verfügt der CAN-Tester über ein eigenes CANopen-Object-Dictionary, dessen Einträge editiert werden können. Die Beschreibung eines CANopen-ODs kann aus EDS-Dateien importiert werden; danach können auch "Werte" per SDO aus einem CANopen-Device gelesen und in Form einer DCF-Datei (Device Configuration File) exportiert werden. Diese Funktion ist zum Testen komplexerer CANopen-Geräte extrem hilfreich; auch im Zusammenhang mit professionellen CANopen-Konfigurationstools (wie z.B. den CANopen Configuration Manager).
Zum Nutzen der SDO-Client-Funktionalität (d.h. zum "Anstossen" von Schreib- und Lesezugriffen) dienen spezielle Befehle des Kommandointerpreters (sdo.read und sdo.write).
Mit dem CANopen-OD-Browser kann das eigene, oder ein 'fremdes' CANopen-Object-Dictionary ("OD") untersucht werden.
Darüberhinaus bietet der CAN-Tester die Möglichkeit, auch ohne EDS-Datei 'alle' Objekte in einem unbekannten CANopen-Slave zu finden. Dazu im Hauptmenü des CAN-Testers die Funktion Tools ... Scan remote OD into the browser aufrufen. Dabei werden der Reihe nach alle möglichen Objekt-Indizes (0x0000...0xFFFF) 'ausprobiert', was sehr lange dauern kann. Um das Einscannen zu beschleunigen, kann der gescannte Index-Bereich daher vor dem Start eingegrenzt werden. Details zum OD-Scanner finden Sie in einer gesonderten Datei.
Öffnen des OD-Browsers für ein externes OD (per SDO) : Im Hauptmenü des CAN-Testers per Tools...Open Remote CANopen OD Browser .
Öffnen des OD-Browsers für das eigene OD (des CANopen-Testers) : Im Hauptmenü des CAN-Testers per Tools... Local CANopen OD Browser .
Die Spalten in der Tabelle haben folgende Bedeutung:
Object
Hier stehen Objekt-Index und -Subindex in hexadezimaler Form.
Name
Der Name des Objektes; stammt i.A. aus dem EDS-File. Bei aus einem 'unbekannten' CANopen-Slave eingelesenen ODs versucht der CAN-Tester, den Namen der wichtigsten Objekte zu 'erraten' (was im Falle der Objekte im Kommunikationsprofil meistens auch passt).
Data Type
Datentyp nach CANopen, allerdings nicht als numerischer Code, sondern als Klartext.
Access
Zugriffsrechte aus dem EDS-File (wenn vorhanden bzw geladen).
Display
Definiert, wie der CAN-Tester die Daten anzeigen soll: hex = Hexadezimal, dec = Dezimal, asc = ASCII (Text) .
Value
Aktueller Wert.
Ähnlich wie beim Befehl sdo.r (Lesezugriff per SDO auf ein bestimmtes Objekt) wird auch hier
bei 'sehr großen Objekten' (Fachchinesch : 'DOMAIN') nicht der Inhalt, sondern der Name einer Datei angezeigt,
in der der CAN-Bus-Tester den Inhalt abgespeichert hat. Sehr praktisch beispielsweise beim
Auslesen einer "EDS-Datei" aus dem Gerät selbst (Objekt 0x1021, z.B. bei MKT's CANopen-Buskoppler).
Size
Größe der Objektdaten, gemessen in BYTES. Beim Datentyp "Visible String" ist dies nicht die maximale Stringlänge, sondern die aktuelle. Leider gibt es keine Möglichkeit, die maximale Länge eines Objektes per SDO-Lesezugriff zu ermitteln !
Counters
Zählerstand für Lesezugriffe (links) und Schreibzugriffe (rechts). Traten beim Zugriff per SDO Fehler auf, werden auch diese gezählt; in der Spalte "Counters" steht dann z.B. ERR=3 (d.h. beim Schreib- oder Lesezugriff sind drei Fehler aufgetreten). Ursache ist oftmals ein Schreibzugriff, den der Prüfling aus irgendwelchen Gründen abgewiesen hat (z.B. Versuch den Inhalt eines "Read Only"-Objektes zu überschreiben.
Mit dem Funktionen 'Load' bzw 'Save' kann eine elektronische Beschreibung des ODs aus einer Datei importiert oder in einer Datei gespeichert werden. Zu den unterstützten Dateiformaten zählt auch das für CANopen übliche EDS-Format (electronic datasheet, oder auch electronic device specification).
Mit der Funktion 'Read' werden alle Werte neu per SDO eingelesen, und sofort in der Tabelle angezeigt. Dieser Vorgang kann, je nach Umfang des ODs, einige Sekunden dauern.
Werte (in der Tabellenspalte 'Value') können auch editiert werden. Beim Abschluss der Eingabe mit der ENTER-Taste kann der Wert dann per SDO in das abgesetzte CANopen-Gerät geschrieben werden. In vielen Fällen ist es aber einfacher, dies mit den im folgenden Kapitel beschriebenen Interpreter-Kommandos zu erledigen.
Nach dem Auslesen eines OD's per SDO kann die so gewonnene "CANopen-Konfiguration" (d.h. die Summe aller im CANopen-OD eines Gerätes verfügbaren "Werte") in einer CANopen-konformen DCF-Datei (device configuration file) abgelegt werden. Wählen Sie dazu im Fenster des "Remote CANopen OD Browsers" die Funktion
Save , wählen als Dateityp "Device Configuration File (*.dcf)", und dann den Namen der Zieldatei (und ggf. das Ziel-Verzeichnis). Anschließend kann die so erzeugte Datei z.B. mit einer anderen Konfiguration (d.h. einem anderen DCF) verglichen werden. Dazu eignen sich Datei-Vergleichs-Utilities wie die im glorreichen(!) Total Commander integrierte Funktion Files ... Compare by Content . Voneinander abweichende Werte (und Parameter) werden beim Total Commander in der Vergleichsliste rot markiert; mit den Buttons "Previous Difference" und "Next Difference" kann man sehr schnell alle Unterschiede in den beiden miteinander verglichenen (Text-)Dateien finden.
Die Spezifikation von EDS und DCF finden Sie übrigends in CiA (CAN in Automation) DS 306. Bei der Erstellung des CAN-Testers diente Draft Standard 306 V1.3 (vom 1. Januar 2005) als Grundlage für das Format der importierten und exportierten EDS- und DCF-Dateien. Das für unsere Zwecke unnötig komplexe, auf XML basierende "XDD"-Format wird nicht unterstützt.
Die Strukturen von EDS und DCF sind nahezu identisch; der Unterschied ist lediglich das Vorhandensein der Einträge mit dem Schlüssel "ParameterValue" . Einige Beispieldateien (EDS und DCF) finden Sie im Unterverzeichnis "Objects" . Die Datei MKTview2_DCF_Import_Test.dcf kann z.B. zu Testzwecken in MKT's "MKT-View II / CANopen" geladen und wieder ausgelesen werden.
Hinweis: Das grauenhaft komplizierte PDO-Mapping wird z.Z. vom CAN-Tester nicht unterstützt. Der Grund liegt darin, daß für den (CANopen-konformen) Schreibzugriff auf die PDO Mapping Parameter nicht einfach der Reihe nach alle Subindizes beschrieben werden dürfen, sondern zunächst der PDO "ungültig" gemacht werden muss, dann die Anzahl gemappter Objekte auf Null gesetzt, anschließend die gemappten Objekte in die passenden Subindizes geschrieben, danach die Anzahl gemappter Objekte auf die tatsächlich vorhandene Anzahl gesetzt werden muss; anschließend der PDO wieder "gültig" gemacht werden muss; .... ; und zu guter Letzt die Konfiguration dauerhaft abgespeichert und ein Node-Reset ausgelöst werden muss (damit die neue Konfiguration verwendet wird). Aus diesem Grund empfehlen wir für die Konfiguration der PDOs unbedingt die Anschaffung eines geeigneten CANopen-Konfigurationstools (z.B. "CANopen Configuration Manager" oder vergleichbare Produkte) .
@print sdo.r($1008.0) ; show device name (as "visible string")
@I=1 ; Read all 32bit floating point variables (object 0x4008)
@N=sdo.r($4008.0) ; how many variables do we have FOR THIS TYPE ?
@repeat
@print "AppVar4008.%02lX = %lg (FLT32)",I,sdo.r($4008.I,F32)
; 32 bit float !!
@I=I+1
@until(I>N)
Das letzte Beispiel stammt aus dem Test-Script
"CanopenTerminalTest.cts",
mit dem in einer Schleife alle Subindizes von Objekt 0x4008 gelesen werden.
In diesem Fall muss der Datentyp (hier : FLT32 = 32-Bit floating point) als
Argument beim Aufruf der sdo.read-Funktion übergeben werden, weil der
Interpreter andernfalls einen 32-Bit-Integer-Typ verwenden würde. Grund:
Beim Lesezugriff per SDO erfährt der SDO-Client zwar, wie viele Bytes
gelesen wurden, nicht aber den Datentyp. Per Default geht der Interpreter
immer von Integer-Typen aus. Als Datentyp können die CANopen-Datentyp-Codes,
oder besser (lesbarer) die folgenden symbolischen Konstanten verwendet werden,
ggf. auch abgekürzt. Alle Symbole in einer Zeile der folgenden Auflistung
entsprechen dem gleichen CANopen-Datentyp .
Bei 'sehr großen Objekten' (CANopen-Fachchinesisch : 'DOMAIN') liefert die Funktion sdo.r() nicht den Inhalt,
sondern den Namen einer Datei, in der der CAN-Bus-Tester den Inhalt abgespeichert hat.
Der Dateiname wird automatisch aus dem Objekt-Index und -Subindex erzeugt, mit dem Vorsatz 'Readout_Obj'
um zu verdeutlichen, daß es sich bei dieser Datei um einen aus einem CANopen-Objekt ausgelesenen Wert handelt.
Beispiel zum Auslesen einer "EDS-Datei" aus dem Gerät selbst (Objekt 0x1021, funktioniert z.B. mit MKT's CANopen-Buskoppler):
@sdo.w ($1017.0,U16, 100 ) ; set heartbeat producer time to 100
milliseconds
Siehe auch : Übersicht aller Interpreterfunktionen und -Kommandos des CAN-Testers
Die folgenden elementare Datentypen waren in CiA DS301 V4.0 auf Seite 9-58
definiert.
Hinweis: Bei weitem nicht alle dieser Typen werden vom CAN-Tester
unterstützt !
Der "Index" eines Datentyps bezieht sich auf das Object Dictionary eines
jeden CANopen-Knotens (dient nur zu Definitionszwecken, unter diesen Indizes
werden Sie bei den meisten CANopen-Knoten nichts auslesen
können !)
| Name | Index | Size in bits | Remarks |
| BOOLEAN | 0x01 | ?? | we use 8 bits for this ! |
| INTEGER8 | 0x02 | 8 | |
| INTEGER16 | 0x03 | 16 | |
| INTEGER32 | 0x04 | 32 | |
| UNSIGNED8 | 0x05 | 8 | |
| UNSIGNED16 | 0x06 | 16 | |
| UNSIGNED32 | 0x07 | 32 | |
| REAL32 | 0x08 | 32 | floating point, not fully supported |
| VISIBLE_STRING | 0x09 | X | not supported |
| OCTET_STRING | 0x0A | X | not supported |
| UNICODE_STRING | 0x0B | X | not supported |
| TIME_OF_DAY | 0x0C | not supported | |
| TIME_DIFFER | 0x0D | not supported | |
| BIT_STRING | 0x0E | not supported | |
| DOMAIN | 0x0F | not supported | |
| INTEGER24 | 0x10 | not supported | |
| REAL64 | 0x11 | not supported | |
| .... | 0x12..0x16 | other exotic types, not supported | |
| reserved | 0x17 | ||
| .... | 0x18..0x1B | very exotic types, not supported | |
| reserved | 0x1C..0x1F | ||
| PDO_COMM_PAR | 0x20 | 8 + x | |
| PDO_MAPPING | 0x21 | 8 + n*32 | |
| SDO_PARAMETER | 0x22 | 8 + x | |
| IDENTITY | 0x23 | 8 + 4*32 |
Siehe auch:
<noch keine deutsche Übersetzung verfügbar>
The table below shows some error codes that may occur during SDO upload or
download.
Most of these error codes are taken from CANopen DS301 V4.
Some of these errors may also be caused by external devices on the CAN bus.
For a more sophisticated explanation of these errors you should check the
CiA literature or other CAN protocol descriptions.
| SDO Error Code | Meaning |
| 0x05030000 | TOGGLE-BIT NOT ALTERNATED |
| 0x05040000 | SDO-PROTOCOL TIMED OUT |
| 0x05040001 | COMMAND SPECIFIER NOT VALID OR UNKNOWN |
| 0x05040002 | INVALID BLOCK SIZE |
| 0x05040003 | INVALID SEQUENCE NUMBER |
| 0x05040004 | CRC ERROR |
| 0x05040005 | OUT OF MEMORY |
| 0x06010000 | UNSUPPORTED ACCESS TO AN OBJECT |
| 0x06010001 | ATTEMPT TO READ A WRITE-ONLY OBJECT |
| 0x06010002 | ATTEMPT TO WRITE A READ-ONLY OBJECT |
| 0x06010047 | UNSUPPORTED ACCESS, INTERNAL INCOMPATIBLE |
| 0x06020000 | OBJECT DOES NOT EXIST IN DICTIONARY |
| 0x06040041 | OBJECT CANNOT BE MAPPED TO THE PDO |
| 0x06040042 | MAPPED OBJECTS WOULD EXCEED PDO LENGTH |
| 0x06040043 | GENERAL PARAMETER INCOMPATIBILITY |
| 0x06040047 | GENERAL INTERNAL INCOMPATIBILITY |
| 0x06060000 | ACCESS FAILED DUE TO HARDWARE ERROR |
| 0x0606002F | ACCESS FAILED DUE TO CAN ERROR |
| 0x06070010 | DATA TYPES DO NOT MATCH |
| 0x06070010 | LENGTH OF PARAM DOES NOT MATCH |
| 0x06070012 | LENGTH OF PARAM TOO HIGH |
| 0x06070013 | LENGTH OF PARAM TOO LOW |
| 0x06090011 | SUBINDEX DOES NOT EXIST |
| 0x06090030 | VALUE RANGE EXCEEDED |
| 0x06090031 | VALUE RANGE TOO HIGH |
| 0x06090032 | VALUE RANGE TOO LOW |
| 0x06090036 | MAXIMUM VALUE IS LESS THAN MINIMUM VALUE |
| 0x08000000 | GENERAL ERROR |
| 0x08000020 | DATA CANNOT BE TRANSFERRED TO APPLICATION |
| 0x08000021 | .. due to local control |
| 0x08000022 | .. due to device state |
| 0x08000023 | OBJECT DIRECTORY GENERATION FAILS |
Siehe auch: Fehlercodes des CAN-Testers
Zuletzt bearbeitet: 2010-03-08, Wolfgang Büscher (DL4YHF) .