Stichpunkte

Allgemein
	CANopen[1] (http://www.can-cia.de/canopen/) ist ein auf CAN basierende Schicht-7-Kommunikationsprotokoll
	welches hauptsächlich in der Automatisierungstechnik verwendet wird
	Das Verbreitungsgebiet von CANopen ist dabei mehr Europa
	Es wurde vorwiegend von Deutschen Klein- und Mittelständischen Firmen initiiert und im Rahmen eines Esprit Projektes unter Leitung von Bosch erarbeitet
	Seit 1995 wird es von der CiA[2] (http://www.can-cia.de/) gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert. Inhaltsverzeichnis showTocToggle("Anzeigen"
	"Verbergen") 1 Grunddienste von CANopen 2 Kommunikationsobjekte 3 Objektverzeichnis 4 Geräteprofile 5 Electronic Datasheets 6 Weblinks [Bearbeiten]
Grunddienste von CANopen
	In CANopen sind mehrere Grunddienste(Dienstprimitive) definiert
	dass ein Ergebnis oder eine bestimmte Nachricht vorliegt Response Antwort der Anwendung auf eine Indication Confirmation Bestätigung an die Anwendung
	dass ein CANopen-Dienst ausgeführt wurde [Bearbeiten]
	Diese Grunddienste sind: Request Anforderung eines CANopen-Dienstes durch die Anwendung Indication Meldung an die Anwendung
Kommunikationsobjekte
	Zeitstempel und Fehler-Nachrichten. [Bearbeiten]
	Netzwerkmanagement-Objekte zur Steuerung des Zustandsautomats des CANopen-Geräts und zur Überwachung der Knoten und weitere Objekte wie Synchronisationsobjekt
	Prozessdatenobjekte (PDO) zum Transport von Echtzeitdaten
	Kommunikationsobjekte können folgendermaßen gegliedert werden in Servicedatenobjekte (SDO) zur Parametrisierung von Objektverzeichniseinträgen
Objektverzeichnis
	Alle Kommunikationsobjekte und alle Anwenderobjekte werden im Objektverzeichnis (OV) zusammen gefasst
	Das OV ist im CANopen-Gerätemodell das Bindeglied zwischen der Anwendung und der CANopen-Kommunikationseinheit
	Jeder Eintrag im Objektverzeichnis steht für ein Objekt und wird durch einen 16-Bit-Index gekennzeichnet
	Ein Index kann wiederum bis zu 255 Subindizes enthalten
	Dadurch können unabhängig von den "`11-Bit-Identifiern"' bis zu 65536 <math>cdot<math> 254 Elemente unterschieden werden
	In Profilen ist die Zuordnung von Kommunikations- und Geräteprofilobjekten zu einem jeweiligen Index genau definiert und somit wird mit dem Objektverzeichnis eine eindeutige Schnittstelle zwischen der Anwendung und der Kommunikation nach außen definiert
	So ist beispielsweise jedem CANopen-Knoten im Netz bekannt
	dass auf Index 1017h das Heartbeat-Intervall zu finden ist und jeder Knoten oder jedes Konfigurationsprogramm kann lesend oder schreibend darauf zugreifen. Indexbereich Verwendung 0000 nicht genutzt 0001-009F Datentypen (Sonderfall) 00A0-0FFF reserviert 1000-1FFF Kommunikationsprofil 2000-5FFF herstellerspezifischer Bereich 5000-9FFF bis zu 8 standardisierte Geräteprofile A000-AFFF Prozessabilder von IEC61131-Geräten B000-FFFF reserviert Für jedes Kommunikationsobjekt existiert eine eindeutige COB-ID(Communication Object Identifier) im Netzwerk
	Die COB-ID besteht aus 32-Bit-Werten
	wobei die ersten beiden Bit jeweils eine objektspezifische Bedeutung haben
	In einem 11-Bit-CAN-Netz haben die folgenden Bits von der Position 29 bis zum 11
	Bit den Wert 0 und die letzten Bits (10 - 0) entsprechen dem CAN-Identifier
	Servicedatenobjekte stellen einen Dienst zum Zugriff auf das Objektverzeichnis bereit. Jedes CANopen-Gerät benötigt mindestens einen SDO-Server
	welcher SDO-Anforderungen von anderen Geräten entgegen nimmt und bearbeitet
	Per Default-Einstellung nutzen Nachrichten zum SDO-Server eines Geräts die Knotennummer des Empfängers + 1536 als COB-ID bzw. als "`Identifier"' für die CAN-Nachricht
	Für die Antwort des SDO-Servers wird als "`Identifier"' die Knotennummer des Senders + 1408 verwendet. Mit diesen relativ hohen und somit niederpriorisierten IDs werden Einträge im OV übertragen
	den Index und den Subindex zu kodieren
	Für diesen SDO-Transfer existiert ein Protokoll
	welches 4 Byte benötigt um die Senderichtung
	Somit bleiben nur noch 4 Byte von den 8 Byte eines CAN-Datenfeldes für den Dateninhalt übrig. Für Objekte deren Dateninhalt größer als 4 Byte ist
	gibt es noch 2 Protokolle zum fragmentierten SDO-Transfer. Im Gegensatz zu dem niederpriorisierten und mit Protokolldaten überladenen SDO-Transfer stellen die Prozessdatenobjekte einen schnellere Möglichkeit zum Transport von Prozessdaten zur Verfügung
	Die zum PDO-Transfer genutzten "`Identifier"' liegen bei Defaulteinstellungen im COB-ID-Bereich von 385 bis 1407 und sind somit höherpriorisiert als die SDO-Nachrichten
	Weiterhin enthalten sie nur Nutzdaten und somit stehen 8 Byte zur Verfügung
	Der Inhalt der Nutzdaten wird über PDO-Mapping-Einträge bestimmt
	welche Daten über ein PDO übertragen werden
	die wie eine Zuordnungstabelle festlegen
	Dies sind Objekte im OV
	Diese Daten sind wiederum Inhalte anderer Objekte des OV
	In einem PDO können auch die Werte mehrerer Objekte übertragen werden und die Empfänger des PDOs können entsprechend ihrer PDO-Mapping-Einträge nur Teile der Daten nutzen
	z.B. in ein digitales Ausgangsobjekt
	geschrieben
	Beim Empfang eines PDOs werden wiederum die Daten entsprechend den Mapping-Einträgen in jeweils andere Objekte des OV
	abgefragt oder synchronisiert geschehen
	ereignisorientiert
	Die Ãœbertragung von PDOs kann zyklisch
	Netzwerkverwaltungsobjekte dienen der Verwaltung des Netzes
	So gibt es u.a
	Nachrichten
	welche eine Zustandsänderung in einen Gerät veranlassen oder globale Fehlermeldungen verbreiten
	Das Sync-Objekt sendet oder empfängt beispielsweise die hochpriorisierte SYNC-Nachricht
	welche der Synchronisation der Knoten im Netz dient und mit dem Zeitstempel-Objekt eine einheitliche Zeit im Netz sicherstellt
	Daneben gibt es im Kommunikationsprofil und insbesondere in den Geräte-Profilen noch eine Vielzahl anderer Objekte. [Bearbeiten]
Geräteprofile
	Für eine Reihe von Geräteklassen und Anwendungen wurden CANopen-Geräteprofile definiert
	welche einem bestimmten Profil entsprechen
	Diese Geräteprofile definieren die Funktionalität und den Aufbau des Objektverzeichnisses für die jeweiligen Geräte. urch die Nutzung von CANopen-Geräten
	wird eine höhere Unabhängigkeit von Geräteherstellern erreicht. [Bearbeiten]
Electronic Datasheets
	sogenannte EDS-Dateien
	nötig
	Für die Nutzung von CANopen-Geräten sind weiterhin elektronische Datenblätter
	Diese Dateien in einem standardisierten Textformat beschreiben sowohl die wichtigsten Parameter der Objekte der Objektverzeichnisse eines Gerätes als auch physikalische Parameter wie z.B. die unterstützten Baudraten
	Konfigurationstools können EDS-Dateien einlesen und mit ihrer Hilfe mit dem jeweiligen Gerät kommunizieren und es ggf. parametrisieren
	Beispiel: Auszug auf einer EDS-Datei  ;This EDS file was created by CANopen Design Tool 2.1.7. [FileInfo] FileName=newProject_line0.eds FileVersion=1 FileRevision=0 EDSVersion=4.0 Description=xxx CreationTime=10:15AM CreationDate=03-06-2005 CreatedBy=me ModificationTime=10:15AM ModificationDate=03-06-2005 ModifiedBy=me [DeviceInfo] VendorName=xxx VendorNumber=0x0 ProductName=test ProductNumber=0x0 RevisionNumber=0x0 OrderCode= BaudRate_10=0 BaudRate_20=0 BaudRate_50=1 BaudRate_125=1 BaudRate_250=1 BaudRate_500=0 BaudRate_800=0 BaudRate_1000=0 DynamicChannelsSupported=0 GroupMessaging=0 LSS_Supported=0 Granularity=0 SimpleBootUpSlave=1 SimpleBootUpMaster=0 NrOfRXPDO=0 NrOfTXPDO=0 [MandatoryObjects] SupportedObjects=3 1=0x1000 2=0x1001 3=0x1018 [1000] ParameterName=Device Type ObjectType=0x07 DataType=0x0007 AccessType=const DefaultValue=0x00000000 PDOMapping=0 [1001] ParameterName=Error Register ObjectType=0x07 DataType=0x0005 AccessType=ro DefaultValue=0x00 PDOMapping=0 Aktuell gibt es innerhalb des CiA[3] (http://www.can-cia.de/) eine Arbeitsgruppe
	welche sich mit der Umstellung der EDS-Dateien auf ein XML-Format beschäftigt. [Bearbeiten]
Weblinks
	CiA-Spezifikationen [4] (http://www.can-cia.org/downloads/ciaspecifications/)

Dieser Artikel basiert auf dem Artikel CANopen aus der freien Enzyklopädie wikipedia und steht unter der GNU Lizenz für freie Dokumentation. In der wikipedia ist eine Liste der Autoren verfügbar.