Canopen Im Ecomat R - IFM Electronic ecomat 100 R 360 Systemhandbuch

6.7. CANopen im ecomat R 360

Die am Anfang des Kapitel 6. beschriebenen Schichten 1 und 2
von CAN regeln die physikalische Anbindung und die Über-
tragung der Daten zwischen den Busteilnehmern. Beim
praktischen Einsatz von CAN in einer Applikation bedeutet
dieses, daß der Programmierer das Datenprotokoll für die
spezielle Anwendung selbst festlegen muß.
Um eine einheitliche Protokollschicht für die Vernetzung der
unterschiedlichen Teilnehmer zu bekommen die die Bedeutung
der übertragenen Daten beschreibt, wurde die Anwendungs-
schicht CAL (CAN Application Layer) als Schicht 7 festgelegt.
CANopen wiederum baut auf CAL auf und definiert, welche
Daten mit welchen CAL-Diensten übertragen werden sollen.
Außerdem ist festgelegt was die Daten für den jeweiligen
Gerätetyp (E/A-Modul, Antriebe, Drehgeber usw.) bedeuten.
Diese Festlegungen ermöglichen es dem Applikations-
programmierer ohne großen Protokollaufwand hersteller-
übergreifend auf alle CANopen-fähigen Komponenten zuzu-
greifen. CANopen-Teilnehmer, die der gleichen Gerätefamilie
angehören haben ihre Daten auf die gleiche Art und Weise
organisiert. Die Eigenschaften dieser Geräteklassen werden in
den „Device Profiles" (DS-40x) zusammengefaßt.
Trotz dieser Festlegung bleibt die Grundstruktur von CAN
erhalten, die es jedem Busteilnehmer ermöglicht Nachrichten
(Daten) auf das Netzwerk zu geben. Lediglich der
Netzwerkmaster (NMT-Master) ist einmalig vorhanden und dient
hauptsächlich zum hochfahren und zur Überwachung des
Systems.
Die im folgenden Text beschriebenen Mechanismen sollen
einen groben Überblick über die Funktion von CANopen geben.
Um das CANopen-Protokoll in seiner gesamten Leistungs-
fähigkeit optimal für die jeweilige Applikation zu nutzen, wird auf
weiterführende Literatur verwiesen (Informationen über CAN in
Automation e.V. (CiA), Erlangen).
Allgemeines zu CANopen Grundsätzlich besitzt jeder CANopen Knoten ein Objekt-
verzeichnis, das über „Service Data Objects" (SDOs) ange-
sprochen werden kann. Zusätzlich stehen mindestens zwei
„Process Data Objects" (PDOs) zum Senden und Empfangen
von Prozeßdaten, ein „Nodeguarding Object" zur Realisierung
einer Netzwerküberwachung, sowie ein „Emergency Object" zur
Anzeige von Fehlerzuständen zur Verfügung.
Die objektorientierten Identifier (11 Bit) werden unter CANopen
als „CAN Object Ids" (COB-IDs) bezeichnet. Über die 4
höchstwertigen Bits (MSBs) werden diese in 16 Gruppen
eingeteilt. Die verbleibenden 7 Bits werden zur Unterscheidung
von 127 CANopen Knoten genutzt. Hierdurch ist eine eindeutige
Zuordnung der einzelnen Objekttypen zu den Knoten gegeben.
Bei dieser Festlegung handelt es sich um eine Default-
Zuordnung.
Seite 45