(gilt
nur für Terminals mit CANopen DS301 V4 und 32-Bit-CPU (ARM), aber nicht
für Geräte mit 8- oder 16-Bit-CPU)
(gilt
nur für Terminals mit CANopen DS301 V4 und 32-Bit-CPU (ARM), aber nicht
für Geräte mit 8- oder 16-Bit-CPU)
Dieses Dokument beschreibt eine Sonderfunktion im "UPT-Programmiertool 2"
zum Erzeugen von CANopen-EDS (Electronic Datasheet) oder DCF (Device
Configuration File). Darüberhinaus sind einige Tipps und Hinweise zum Importieren
der so erzeugten Dateien in CoDeSys enthalten.
Stand: 2013-05-08 (ISO 8601)
Autor: Wolfgang Büscher, MKT Systemtechnik
Siehe auch (Links zu anderen Dokumenten):
Die Konfiguration des Terminals bezüglich der CANopen-Kommunikation
kann als DCF-Datei exportiert und von einer geeigneten SPS-Projektierungssoftware
(z.B. CoDeSys mit "CANopen-Master") importiert werden.
Dadurch kann der SPS-Entwickler direkt mit den 'sprechenden' UPT-Variablen-Namen
arbeiten, statt mit den 'nichtssagenden' (weil fest im EDS und in der Geräte-Firmware verankerten)
Namen im CANopen-Objektverzeichnis (OD).
Wählen Sie dazu im Hauptmenü des Terminal-Programmiertools die
Funktion
Datei .. Erzeuge CANopen EDS oder DCF .. Erzeuge DCF .
Der EDS/DCF-Generator listet zur Kontrolle alle Alias-Namen auf der Registerkarte "Aliases" auf (näheres dazu im folgenden Kapitel), z.B.:
Auf den weiteren Registerkarten können die Einträge im
Objektverzeichnis, und die Beschreibungen in den Abschnitten "File Info"
und "Device Info" kontrolliert werden.
Im Idealfall sind aber keine weiteren Eingaben für die Erzeugung der
DCF-Datei mehr nötig, weil das Programmiertool alle benötigten
Informationen in das DCF (nicht EDS!) automatisch übernimmt. Dazu
zählen unter Anderem:
In der vom UPT-Programmiertool erzeugten DCF-Datei sind die Alias-Namen wie
in CANopen DS 306 beschrieben als 'Denotations' enthalten, siehe:
Beispiel aus einer vom Terminal-Programmiertool erzeugten DCF-Datei :
4003sub1] ParameterName=Application Vars 16 bit signed_1 Denotation=FourSines1 ; dies ist der "Alias" (Name einer UPT-Variablen) DataType=0x3 DefaultValue=0 AccessType=rw ParameterValue=0 PDOMapping=1
Falls Ihre SPS-Projektierungssoftware diese im CANopen-Standard vorgesehene (und nach Meinung des Autors sehr praktische) Funktion nicht unterstützt, wenden Sie sich bitte an den Hersteller. Notfalls hilft Ihnen die oben gezeigte Liste (Registerkarte "Aliases" mit CANopen-Objekt-Namen im EDS/DCF-Creator) als Referenz bei der Erstellung des SPS-Programms. Zu diesem Zweck kann die Liste als 'normaler Text' über die Windows-Zwischenablage in einen beliebigen Text-Editor übernommen werden.
Bei einem Test mit CoDeSys V3.4 funktionierte die empfohlene 'Denotation'-Methode, d.h. die vom UPT-Programmiertool erzeugte DCF-Datei (nicht EDS !) wurde beim Import per 'Geräte-Repository' mit den Alias-Namen eingelesen. Bei der Auswahl von Elementen im Objektverzeichnis zeigt CoDeSys im Dialog 'Element aus dem Objekverzeichnis auswählen' die 'Denotations' in der Spalte 'Name' an (statt der 'Default-Namen im OD):
Näheres dazu im Kapitel Hinweise zu CoDeSys.
Falls Ihre SPS-Projektierungssoftware die 'Denotation' im
DCF ignoriert, kann alternativ für jedes konfigurierte
Anzeigeterminal auch ein eigenes (individuelles) EDS erzeugt
werden, in dem dann statt der Standard-Objekt-Namen die Alias-Namen
als "ParameterName" verwendet werden. Für jedes konfigurierte Gerät
eine eigene DCF-Datei zu verwenden ist zwar nicht 'im Sinne des Erfinders'
(CANopen), aber mit der folgenden Einstellung auf der Registerkarte 'Options'
im EDS/DCF-Creator möglich:
Auf der Registerkarte 'Device Commissioning' können die folgenden
Konfigurationswerte eingegeben werden, die zum Erzeugen einer
DCF-Datei benötigt werden:
Details finden Sie in DS 306 V1.3.0 aus kaum nachvollziehbaren Gründen
nur im Kapitel
5.3.3.3 Network variable values.
Im "Members-Only"-Bereich der CiA-Webseite konnten CiA-Mitglieder seit Juni
2011 eine stark verbesserte "CiA 306 Work Draft Part 1", Version 1.3.3
herunterladen, in der das Thema Device Commisioning in einem eigenen
Kapitel erläutert wird:
7.3.4 Device Commissioning.
Im UPT-Programmiertool wird der Node-ID für das 'Device Commissioning' von der Registerkarte Einstellungen im Hauptfenster übernommen (aus dem Feld 'Node-ID des Terminals', rechts oben).
Zu der Bedeutung der weiteren Parameter unter 'Device Commissioning' ziehen Sie bitte die einschlägige CANopen-Fachliteratur zu Rate (z.B. DS 306 in der neuesten verfügbaren Version).
> NodeID shall indicate the CANopen device's address (UNSIGNED8),> NodeName shall indicate the node name (maximal 246 characters),> Baudrate shall indicate the CANopen device's baudrate (UNSIGNED16),> NetNumber shall indicate the number of the network (UNSIGNED32),> NetworkName shall indicate the name of the network (max 243 characters),> CANopenManager shall indicate the CANopen device is the CANopen manager> (BOOLEAN, 1 = CANopen manager, 0 or missing = not the manager),> LSS_SerialNumber shall indicate the serial number (index 1018h, sub-index 04h),> (UNSIGNED32).
CoDeSys ist (zumindest in der vom Autor getesteten Version 3.4 SP4 Patch
2) glücklicherweise in der Lage, die 'Denotations' anzuzeigen (d.h. die im
UPT-Programmiertool passend zu ihrer 'Bedeutung' benannten Objekte),
statt nur der nichtssagenden Objektnamen im CANopen-Objekt-Verzeichnis.
Beispiel:
Details zum 'Einhängen' eines CANopen-Slaves in eine CoDeSys-Steuerung entnehmen Sie bitte der einschlägigen Fachliteratur - eine detailierte "Step-by-Step"-Anleitung würde den Rahmen dieser Dokumentation sprengen. Hier nur der prinzipielle Ablauf, mit einigen Tips des Autors dieser Beschreibung (der zum Zeitpunkt der Erstellung dieses Dokuments seine ersten Erfahrungen mit CoDeSys machte):
(ToDo: Geht das auch mit weniger
Klickibunti ? )
Anhand der Werte aus der DCF-Datei (die, wie weiter oben beschrieben,
mittlerweile in der 'Geräte-Repository' enthalten ist) sollte an dieser
Stelle auch das mit dem UPT-Programmiertool (! - nicht mit CoDeSys - !)
eingestellte PDO-Mapping im CoDeSys-Projekt bekannt sein.
Auf der Registerkarte PDO-Mapping kann dies in CoDeSys kontrolliert
werden:
Erhalten Sie nicht die erwartete Anzeige in CoDeSys, kontrollieren Sie die folgenden Punkte:
Üblicherweise erfolgt die Kommunikation zwischen SPS und externem CANopen-Gerät per Prozessdaten (PDO). Der Aufbau und die Kommunikationsparameter der Prozessdaten-Objekte sind der CoDeSys-Steuerung an dieser Stelle bereits bekannt (da sie, wie oben beschrieben, aus der vom UPT-Programmiertool erzeugten DCF-Datei importiert wurden).
Vermutlich reicht es, die per PDO übertragenen 'Kanäle' auf der Registerkarte
"CANopen I/O Abbild" mit entsprechenden Variablen zu verbinden.
Im unten gezeigten Screenshot wurden in der Spalte 'Variable' (links) die gleichen Namen verwendet,
die in der Spalte 'Kanal' bereits vorhanden waren (und die vermutlich von CoDeSys aus den 'Denotations'
in der DCF-Datei importiert wurden) :
Ob dies allerdings 'der richtige Weg' ist, war fragwürdig, denn (nach der oben beschriebenen Änderung):
Der Autor stellte daraufhin weitere Experimente mit Codesys zunächst ein.
Bei der Arbeit mit CoDeSys ist zu beachten, dass für die Datentypen
leider völlig andere Namen als im CANopen-Standard verwendet
werden.
Speziell beim Datentyp 'INT' ist Vorsicht geboten, da dieser bei modernen
C-Compilern i.d.R. 32 Bit breit ist. Nicht so bei CoDeSys:
Hier besteht 'INT' offenbar nur aus 16 Bit, und 'S' (steht vermutlich für
"short") kennzeichnet 8, nicht 16 Bit !
| Datentyp | Name bei CANopen ("CiA 301", ehemals "DS 301") |
Name in CoDeSys | Vergleichbare Typen in "C" |
| 8 bit signed integer | INTEGER8 |
SINT |
signed char |
| 16 bit signed integer | INTEGER16 |
INT (!!!) |
short, short int |
| 32 bit signed integer | INTEGER32 |
DINT |
int, long, long int |
| 8 bit unsigned integer | UNSIGNED8 |
USINT |
unsigned char, BYTE |
| 16 bit unsigned integer | UNSIGNED16 |
UINT (!!!) |
unsigned short, WORD |
| 32 bit unsigned integer | UNSIGNED32 |
UDINT |
unsigned long, DWORD |
| 32 bit floating point | REAL32 |
REAL |
float |
| Zeichenkette ? | VISIBLE_STRING | ? | char[] |
Hinweis: Da die meisten CANopen-Slaves (auch die 'ARM-Views') kein bitweises,
sondern nur byte-weises PDO-Mapping unterstützten, macht der Datentyp
'Boolean' im Zusammenhang mit der Prozessdaten-Übertragung wenig Sinn,
und ist aus dem Grund in der obigen Tabelle nicht enthalten.
CANopen-Objekte mit dem Datentyp "VISIBLE_STRING" sind ebenfalls nicht
PDO-map-bar, und können (wie BOOLEAN) nur per SDO (Servicedatenobjekt)
übertragen werden.