Das CANopen-Objektverzeichnis des Terminals

(gilt nur für Terminals mit CANopen DS301 V4, z.B. UPT128, UPT320, UPT800, DT85)

Dieses Dokument beschreibt den prinzipiellen Aufbau eines CANopen-Objekt-Dictionaries (im Folgenden als "OD" abgekürzt). Eine 'elektronische' Beschreibung des ODs ist die sogenannte EDS-Datei .

Hinweis: Nicht alle Terminals bieten diese Funktion - nur Geräte mit CANopen seit 2004 (siehe Feature Matrix) !

Inhalt

Siehe auch (Links zu anderen Dokumenten) :



Zweck und Aufbau des CANopen-Objektverzeichnisses

Das Objektverzeichnis (Object Dictionary, OD) stellt die Verbindung zwischen Applikation und CAN-Bus dar, um Daten mit einer Applikation und über den CAN-Bus auszutauschen. CANopen definiert Dienste und Kommunikationsobjekte für den Zugriff auf Einträge des Objektverzeichnisses (z.B. PDO, SDO). Jeder Eintrag wird über Index und Subindex adressiert. Die Eigenschaften eines Eintrages im OD wird über seinen Datentyp und seine Attribute (lesbar, schreibbar..) festgelegt.
Das OD kann bis zu 65536 Indexeinträge und pro Index 0 bis 255 Subindizes enthalten. Die Einträge im OD werden durch die Kommunikationsprofile bzw. Geräteprofile vordefiniert. Ein Beispiel für ein einfaches Geräteprofil für E/A-Module ist z.B. CANopen DS 401, für programmierbare Bedienterminals existierte zur Zeit des Projektbeginns leider noch kein geeignetes Geräteprofil (der Entwurf DSP 403 wurde nie veröffentlicht, und galt immer als "not recommended for implementation").

Einträge im OD sind mit Default-Werten vorbelegbar. Mit Hilfe von SDOs kann ein Wert eines Eintrags geändert werden, insofern es das Attribute zuläßt (read-write und write-only; nicht für read-only und const). Ein Wert kann auch von der Applikation selbst geändert werden (Attribute read-write, write-only und read-only; nicht für const).

Das OD wird auch benötigt, um den Inhalt der Prozessdatentelegramme zu definieren. Dieser Vorgang wird in der CANopen-Literatur als "PDO-Mapping" bezeichnet. Beim Programmiertool für Terminals mit CANopen (außer UPT515) können die in die PDO-Telegramme einzublendenden Objekte bequem aus einer Liste ausgewählt werden, in der nur die PDO-map-baren Objekte aus dem OD des Terminals aufgelistet werden. Die Information, ob ein Objekt in ein Prozessdatentelegramm eingeblendet werden kann, ergibt sich aus dem Attribut des Eintrages im OD.

Aufteilung in standardisierte Profile

Das OD ist anhand der Indexnummern in verschiedene Abschnitte unterteilt:

0x1000 – 0x1FFF: Kommunikationsprofil .
Wird für die Definition der Parameter für die Kommunikationsobjekte und die Ablage von allgemeinen Informationen (Hersteller, Gerätetyp,
Seriennummer, ...) verwendet. Genaue Beschreibung siehe CiA DS 301.
Trotz der 'Standardisierung' wird das Kommunikationsprofil auch im EDS-File eines jeden CANopen-konformen Gerätes beschrieben, wie z.B. in diesem Beispiel für MKT's Anzeige-Terminals mit CANopen V4.
0x2000 – 0x5FFF: Herstellerspezifisches Profil .
Reserviert für die Ablage von herstellerspezifischen Einträgen. Siehe Kapitel "Objekte im herstellerspezifischen Teil des ODs" .
0x6000 - 0x9FFF: Standardisiertes Geräteprofil .
Da für programmierbare Anzeige-Terminals bislang kein Geräteprofil existiert, ist dieser Bereich bei den programmierbaren Terminals bislang noch LEER ! Bei einem E/A-Modul mit DS 401 würden Sie in diesem Bereich z.B. digitale Ein- und Ausgänge finden.
0xA000 - 0xFFFF: Reserviert..
..für zukünftige CANopen-Erweiterungen (nicht für herstellerspezifische Objekte nutzbar)

zurück zur Übersicht


Objekte im herstellerspezifischen Teil des ODs

Um Konflikten mit einem zukünftigen Geräteprofil für programmierbare Bedien- und Anzeigegeräte vorzubeugen, wurde bei MKT's programmierbarem Terminal einige Objekte im herstellerspezifischen Profil abgelegt, die dort "eigentlich" nicht hingehören.

Diese entsprechen von der Funktion her den im (leider nie veröffentlichten) "DSP 403 = Device Profile for Human Machine Interfaces" definierten input- und output-Variablen (dort in den Objekten 0x7000...0x747F). Die von MKT "provisorisch" gewählte Struktur ist allerdings anders, und belegt zwangsweise andere Objekt-Indizes. Der Index in MKT's herstellerspezifischem Profil ergibt sich aus der Addition einer Konstanten (0x4000) und dem Code für den entsprechenden Datentyp. Pro Datentyp stehen i.A. 16 Variablen zur Verfügung, was allerdings im Einzelfall anhand der EDS-Datei überprüft werden sollte (die EDS-Datei eines Terminals ist untrennbar mit der geladenen Firmware verbunden, weil die Terminals bislang nur ein statisches OD enthalten. Sie finden das für "Ihr" Terminal passende EDS-File im Unterverzeichnis eds_files des Programmiertools. Für die meisten Geräte wird ein gemeinsames EDS-File verwendet, um die Variantenvielfalt in erträglichen Grenzen zu halten. Eine Übersicht der verfügbaren EDS-Dateien finden Sie im oben genannten Unterverzeichnis in der Datei readme_eds_files.htm ).

Die bei den meisten programmierbaren Terminals (von MKT) vorhandenen Objekte im herstellerspezifischen Teil des ODs sind:

0x4000...0x401F  Schreib- und lesbare "Variablen", Index = 0x4000 + <Datentyp nach CANopen>.
Jedes dieser Objekte enthält mehrere Subindizes. Subindex 0 enthält die "Anzahl Variablen dieses Typs", Subindizes 1..10 die eigentlichen Daten. Subindizes 1..10 können in Prozessdatenobjekte (PDO) gemappt werden, Subindex 0 nicht. Subindizes 1..10 können darüberhinaus mit Display-Variablen verbunden werden.

0x4001 Application Variable "BOOL"
(nicht vollständig implementiert, verwenden Sie Objekt 0x4005)
0x4002 Application Variable "Int8"
8 Bit mit Vorzeichen, entspricht dem C-Typ "signed char"
0x4003 Application Variable Integer16
Dieser Datentyp entspricht dem C-Typ "short integer".
0x4004 Application Variable Integer32
Dieser Datentyp entspricht dem C-Typ "long integer".
0x4005 Application Variable Unsigned8
Dieser Datentyp entspricht dem C-Typ "BYTE".
0x4006 Application Variable Unsigned16
Dieser Datentyp entspricht dem C-Typ "WORD".
0x4007 Application Variable Unsigned32
Dieser Datentyp entspricht dem C-Typ "DWORD".
0x4008 Application Variable "Real32"
Dieser Datentyp entspricht dem C-Typ "float".
0x4009 Application Variable "Visible String"
(nicht komplett implementiert, nicht in PDO einblendbar)

Hinweis: Ältere Geräte enthielten maximal zehn Variablen pro Datentyp. Neuere Geräte mit 32-Bit-CPU bieten seit März 2010 dagegen vierzig Variablen pro Datentyp (Codename: "Monster-OD"). Aus diesem Grund existieren seit März 2010 auch zwei unterschiedliche EDS-Dateien für die programmierbaren Terminals .

Tip:
Im Installationsarchiv ist eine Testdatei namens 'Obd_Test.upt' enthalten. Mit diesem Anzeigeprogramm kann das Verhalten der oben aufgeführten Objekte getestet werden; ferner demonstriert es wie "normale" Display-Variablen (des Terminals) mit diesen Objekten verknüpft werden (siehe Variablen 'OdTstI32' alias Objekt 0x4004.01, und 'OdTstF32' alias Objekt 0x4008.01 :  Objekt-Index und -Subindex wird auf der Registerkarte 'Variablen' in der Spalte 'OD-Index' eingetragen) .

Objekt 0x5000

digitiale Eingänge, 'Onboard' (optional)
PDO-map-bares Objekt mit bis zu 32 digitalen Eingängen, in 8-bit-Gruppen.
Nur bei bestimmten Geräten vorhanden, z.B. "UPT128" mit Onboard-I/O, oder "UPT320 I/O".
Funktion und Aufbau entspricht weitgehend Objekt 0x6000 aus CANopen DS401 (für I/O-devices).


Objekt 0x5001

Tastatur-Matrix.
Aktueller Zustand der Tastaturmatrix in 8-Bit-Gruppen (ähnlicher Aufbau wie "digitale Eingänge" in CANopen DS401 Objekt 0x6000). Subindex Null enthält, wie bei CANopen üblich, die den höchsten Subindex.
Subindex 1 enthält den Zustand der ersten 8 Tasten der weiter unten beschriebenen "MKT-Standard-Tastatur-Matrix".
Ein gesetztes Bit entspricht einer gedrückte Taste, ein gelöschtes Bit einer nicht gedrückten Taste.
Dieses Objekt ist PDO-map-bar, und kann (mit PDO-Transmission-Type '254') zum ereignisgesteuerten Senden eines TPDOs verwendet werden.

Die Standard-Tastatur-Matrix wird seit Oktober 2007 in allen 'neueren' Geräten von MKT verwendet, selbst wenn dort nicht alle der unten aufgeführten Tasten existieren, und unabhängig von der verwendeten Hardware.
Der Aufbau entspricht weitgehend der Interpreter-Funktion "km" bzw. der Script-Funktion system.dwKeyMatrix (keyboard matrix):

Hinweis für Entwickler: Die "Standard-Matrix-Bits" sind in der Header-Datei keyc_std2.h definiert.

Objekt 0x5200

digitiale Ausgänge, 'Onboard' (optional)
PDO-map-bares Objekt mit bis zu 32 digitalen Ausgängen, in 8-bit-Gruppen.
Nur bei bestimmten Geräten vorhanden, z.B. "UPT128" mit Onboard-I/O, oder "UPT320 I/O".
Funktion und Aufbau entspricht weitgehend Objekt 0x6200 aus CANopen DS401 (für I/O-devices).

Objekt 0x5201

'Front Panel Lamps' (z.B. in der Tastaturfolie integrierte Signal-LEDs)
Nur bei bestimmten Geräten vorhanden, z.B. "UPT128" .
Subindex Null enthält, wie üblich, den maximalen Subindex dieses Objektes.
Mit dem 8-Bit-Datum in Subindex 1 können die ersten acht LEDs gesteuert werden.

Objekt 0x5202

'Backlight Control' (Steuerung der Hintergrundbeleuchtung des Displays)
Subindex Null enthält, wie bei CANopen üblich, den maximalen Subindex dieses Objektes (i.A. 4; falls nicht weitere 'Sonder-Optionen' vorhanden sind)
Subindex 1 : aktueller Zustand der Hintergrundbeleuchtung: 0 = nicht initialisiert, 1=an, 2=aus wegen Timeout.
Subindex 2 : konfigurierte Helligkeit, 8 Bit unsigned (0...255) .
Subindex 3 : konfigurierte Timeout-Zeit in Sekunden . Nicht PDO-map-bar.
Subindex 4 : Backlight Timeout Timer. Liefert den aktuellen Stand des Timeout-Timers. Dieser wird bei jedem Tastendruck mit der konfigurierten Timeout-Zeit geladen, und zählt danach im Sekundentakt abwärts. Beim Erreichen von Null wird die Beleuchtung abgeschaltet. Der Zählerstand ist PDO-map-bar, und kann (bei geeignetem PDO transmission type) zum ereignisgesteuerten Senden eines PDO-Telegramms verwendet werden. Die übergeordnete Steuerung kann daran z.B. erkennen, wenn am Anzeigeterminal wegen Nicht-Aktivität "das Licht ausgeht" .

Objekt 0x5111

Übertragung der Terminal-Applikation (*.upt) zwischen Terminal und Programmiertool
Mit diesem Objekt wird das Terminal vom Programmiertool für die Übertragung des Anwenderprogramms vorbereitet. Die Übertragung selbst erfolgt zeilenweise, wobei ein ähnliches Format wie bei der Ablage der Applikation als *.upt-Datei (Textfile!) verwendet wird. Jede Zeile wird als CANopen-Datentyp "visible string" übertragen, allerdings -möglicherweise- verschlüsselt.

zurück zur Übersicht


Datei: ..?..\uptwin1\help\objdict_49.htm
Autor: W.Büscher, MKT Systemtechnik
Letzte Änderung: 2010-12-21 (ISO8601, YYYY-MM-DD)

zurück zur Übersicht