Grundlagen zu CANopen

Transkript

1 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 1 Grundlagen zu CANopen Die Vorteile offener Feldbus-Systeme sind hinlänglich bekannt: der Aufbau von Multivendoranlagen wird ermöglicht, der Projektierungs- und Anpassungsaufwand je Applikation sinkt. Für offene Systeme müssen jedoch eine Reihe von Voraussetzungen erfüllt werden. Dies sind: einheitliche untere Ebenen des ISO/OSI Modells, einheitliche Anwendungsschicht, standardisierte Profile Bei CAN ist die erste Voraussetzung für die Schichten 1 und 2 durch die Normen ISO-DIS und ISO-DIS gegeben. Diese werden im Automatisierungsbereich durch die Empfehlungen des Anwendervereins CiA für Steckerbelegung und Übertragungsraten ergänzt. Im Bereich der Anwendungsschicht hat CiA den Standard CAL (CAN Application Layer ) hervorgebracht. Device Device Device Profile Device Profile Profile DS401 Profile DS401 DS402 IO DS402 IO Modules Modules Motion Motion Control Control CANopen Communication Profile (CiA DS301,DS302...) CAN Application Layer (CAL) (CiA DS ) Device Device Profile Profile DS406 DS406 Encoder Encoder Data Data Link Link Layer (ISO (ISO 11898) High-Speed Transceiver and and Bit-Timing (IS0 (IS011898) bus lines Bild: CANopen eingeordnet im ISO/OSI-Schichtenmodell Bei CANopen wurde zunächst das Kommunikationsprofil sowie eine Bauanleitung für Geräteprofile entwickelt, in der mit der Struktur des Objektverzeichnisses und den allgemeinen Kodierungsregeln der gemeinsame Nenner aller Geräteprofile definiert ist. Auf dieser Basis werden nun Geräteprofile für typische Automatisierungskomponenten entwickelt wie z.b. servogeregelte Antriebe, Low-Level -Sensoren, digitale und analoge Ein- Ausgabebaugruppen, Encoder, serielle Schnittstellen, Identifizierungs-Systeme, Bildverarbeitungssysteme und intelligente Gateways.

2 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 2 CANopen -Kommunikationsprofil Das CANopen Kommunikationsprofil (dokumentiert in CiA DS-301) regelt das wie der Kommunikation. Wie bei allen anderen Feldbus-Protokollen werden hierbei Echtzeitdaten und Parameterdaten unterschieden. CANopen ordnet diesen vom Charakter her völlig unterschiedlichen Datenarten jeweils passende Kommunikationselemente zu. Process Control State Machine CommunicationProfile DS301 tx rx tx rx SFO NMO SDO PDO COBs! Special Function Object (SFO) -Synchronization (SYNC) -Time Stam p -Em ergency (EM CY)Protocol! Network Management Object (NMO) e.g. - Life/Node-Guarding -Boot-Up,... -E rror ControlProtocol Bild: Kommunikationselemente bei CANopen

3 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 3 Prozeß Daten Objekte (PDO) Prozeßdatenaustausch mit CANopen ist CAN pur, also ohne Protokoll-Overhead. Die Broadcast-Eigenschaften von CAN bleiben voll erhalten, eine Nachricht kann also von allen Teilnehmern empfangen und ausgewertet werden. Die Kommunikation mit Prozeßdatenobjekten entspricht dem Producer- Modell. Daten werden von ihrem Produzent ( beispielsweise einer Ein-Ausgabebaugruppe) auf den Bus gelegt und von einer beliebigen Anzahl von Konsumenten empfangen und verarbeitet. Das statische Master/Slave - Verhalten der meisten anderen Systeme ist hier nicht vorhanden. Hier liegt einer der entscheidenden Vorteile von CANopen. Die PDOs lassen sich wahlweise ereignisgesteuert oder synchronisiert übertragen, wie es etwa in der Antriebstechnik erforderlich ist. Durch den ereignisgesteuerten Modus kann darauf verzichtet werden, ständig das gesamte Prozeßabbild zu übertragen. Es genügt, die Änderung der Daten zu kommunizieren. Damit lassen sich sowohl die Busbelastung als auch die Reaktionszeit des Netzes auf ein Minimum reduzieren. Es wird dadurch eine hohe Kommunikationsleistung bei vergleichsweiser geringer Baudrate erzielt. PDO PDO Producer Write PDO PDO (tx) ID Data Application Objects 0 < 1< 8 byte indication Read PDO (s) PDO Producer PDO CAN Remote Frame Process Data Objects (PDO) response Application Objects 0 < 1< 8 byte Bild: PDO-Protokoll (Producer/-Modell) Die PDOs haben wie angesprochen Broadcastcharakter und unterstützen damit in idealer Weise das Konzept der dezentralen Steuerung. So kann das Eingangsdatum eines E/A-Moduls mehreren Steuerungen gleichzeitig mitgeteilt werden. Ebenso können digitale Eingänge unmittelbar allen Steuerungskomponenten zur Verfügung stehen. Master/Slave-Achsensysteme werden dabei ebenso unterstützt wie Netzwerke mit verteilter Intelligenz.

4 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 4 Service Daten Objekte (SDO) Peer-to-Peer Communication Client Server SDO 1 Data ID 1 ID1 0 to 8 Byte CAN Data Frame 1 Service Data Object (SDO) ID 2 Data confirmation ID2 0 to 8 Byte CAN Data Frame 2 Bild: SDO-Protokoll (Client-Server-Modell) Für Parameterdaten beliebiger Größe steht mit dem SDO ein leistungsfähiger Kommunikationsmechanismus zur Verfügung. Hierfür wird zwischen dem Konfigurationsmaster und den angeschlossenen Geräten ein Servicedatenkanal für Parameterkommunikation ausgebildet. Die Geräteparameter können mit einem einzigen Telegramm-Handshake ins Objektverzeichnis der Geräte geschrieben werden bzw. aus diesem ausgelesen werden. Das Objektverzeichnis strukturiert die Daten eines CANopen- Gerätes in einer übersichtlichen tabellarischen Anordnung. Es enthält sowohl sämtliche Geräteparameter als auch alle aktuellen Prozessdaten, die damit auch über das SDO zugänglich sind. Die Struktur des CANopen-Objektverzeichnisses entspricht hierbei genau derjenigen andere Bussysteme, so daß eine weitgehende Kompatibilität auf Anwenderebene gegeben ist. ObjectDictionaryAccess SDO - Beispiel 1.SDO (tx) COB-ID = 580h+5 Device Byte 0 Byte 1-3: Multiplexor Byte 4-7: Data Command 16-bit-Index 8-bit 1-4 byte parameter Specifier Subindex data Device No 2 (Client) 1.SDO (rx) COB-ID = 600h+5 No 5 (Server) Index Subindex Description Value Object Dictionary Client--> Server Server--> Client Bild: SDOs erlauben den Zugriff auf das Objektverzeichnis

5 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 5 Wichtige Merkmale von SDO und PDO CiA DS 301 (CANopen) Datenarten Kommunikationsprofil PDO (Process Data Object) SDO (Service Data Objekt) -Echtzeitdaten -hochpriore Identifier -max. 8 Bytes -Format vorher vereinbart -CAN pur -keine Bestätigung -System-Parameter -niederpriore Identifier -Daten auf mehreretelegramme verteilt -Daten durch Index adressiert -bestätigende Dienste Bild: Gegenüberstellung von Eigenschaften SDO/PDO

6 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 6 Aufbau des Objektverzeichnisses Index (hex) Object 0000 Reserved F Static Data Types F Complex Data Types F Manufacturer Specific Data Types F Device Profile Specific Static Data Types F Device Profile Specific Complex Data Types 00A0-0FFF Reserved for further use FFF Communication Profile Area FFF Manufacturer Specific Profile Area FFF Standardized Device Profile Area A000-FFFF Reserved for further use Index Object Name Type Acc. M/O (hex) 1000 VAR device type Unsigned32 ro M 1001 VAR error register Unsigned8 ro M 1002 VAR manufacturer status register Unsigned32 ro O 1003 ARRAY pre-defined error field Unsigned32 ro O 1004 Reserved for compatiblity reasons 1005 VAR COB-ID SYNC-message Unsigned32 rw O 1006 VAR communication cycle period Unsigned32 rw O 1007 VAR synchronous window length Unsigned32 rw O 1008 VAR manufacturer device name Vis-String c O 1009 VAR manufacturer hardware version Vis-String c O 100A VAR manufacturer software version Vis-String c O 100B Reserved for compatiblity reasons 100C VAR guard time Unsigned32 rw O 100D VAR life time factor Unsigned32 rw O 100E Reserved for compatiblity reasons 100F Reserved for compatiblity reasons 1010 VAR store parameters Unsigned32 rw O 1011 VAR restore default parameters Unsigned32 rw O 1012 VAR COB-ID time stamp Unsigned32 rw O 1013 VAR high resolution time stamp Unsigned32 rw O 1014 VAR COB-ID Emergency Unsigned32 rw O 1015 VAR Inhibit Time Emergency Unsigned16 rw O 1016 ARRAY Heartbeat Time Unsigned32 rw O 1017 VAR Producer Heartbeat Time Unsigned16 rw O 1018 RECORD identity object Identity ro M ::::: ::::: ::::: ::::: ::::: ::::: 11FF reserved

7 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 7 CANopen Default Identifier CANopen -Geräte können ohne Konfiguration in ein CANopen -Netzwerk eingesetzt werden. Lediglich die Einstellung einer Knotenadresse und die Baudrate über DIP- Schalter ist erforderlich.aus dieser Knotenadresse leiten sich die Identifierzuordnung für die Kommunikationskanäle ab. COB-Identifier Bit-N o.: RTR DLC DATA COB Function Code Module-ID Bild: Default-Identifier-Verteilung spart Konfigurationsaufwand object Function code Resulting COB-ID Communication Parameters at Index NMT SYNC h 1005h,1006h,1007h TIME STAMP h 1012h,1013h EMERGENCY h-FFh 1014h,1015h PDO1 (tx) h 1FFh 1800h PDO1 (rx) h 27Fh 1400h PDO2 (tx) h 2FFh 1801h PDO2 (rx) h 37Fh 1401h PDO3 (tx) h 3FFh 1802h PDO3 (rx) h 47Fh 1402h PDO4 (tx) h 4FFh 1803h PDO4 (rx) h 57Fh 1403h SDO (tx) h 5FFh 1200h SDO (rx) h 67Fh 1200h NMT Life Node-Guarding h 7FFh 1016h,1017h

8 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 8 Sync Telegramm Durch den synchronisierten Modus ist es z.b. möglich, mehrere Achsen einer Kinematik zu synchronisieren, Ausgänge gleichzeitig zu setzen oder Eingänge parallel einzulesen. Somit erfüllt der Synchronisationsmodus die Antriebs-Anforderungen Sync Object Sync-Producer Sync-Producer Sync-s(s) Sync- ID Data Sync- Non Sync- Sync- COB-ID= 80 L=0 indication(s) Time Stamp Time-Stamp Producer Time-Stamp (s) Time Stamp Producer days, ms COB-ID = 256 (100h) 6 Byte TimeOfDay Data indication(s) Time Stamp ID Time Stamp Time Stamp Time Stamp STRUCT OF UNSIGNED28 ms, (after midnight) VOID4 reserved_1, UNSIGNED16 days (since January 1, 1984) TimeOfDay Node und Life Guarding NMT NMT NMT NMT NMT NMT Master Master Master Master Master Master confirmation COB-ID =700+Node-ID Remote Frame Bit 7 Bit 6-0 Toggle-bit Node State Guard-Time time confirmation Remote Frame Bit 7 Bit 6-0 Toggle-bit Node State indication possible Life-Time indication * if guarding error

9 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 9 Netzwerkmanagement Das Netzwerkmanagement unterstützt einen vereinfachten Hochlauf (Boot-Up) des Netzes. Mit einem einzigen Telegramm lassen sich alle Geräte in den Beriebszustand (Operational) versetzen. (1) Power-On Reset Com munication Initialization Pre-Operational (5) (3) (4) (6) Operational Reset Node (2) (11) (14) (9) (10) (7) (13) (12) (8) Stopped Bild: Boot-Up- Mechanismus des Netzwerkmanagement Erklärung der Zustände: Pre-Operational: SDO aktiv, Sync + Node-/Lifeguarding möglich Statusübergänge: CAN-Telegramm mit COB-ID 000h und 2 DatenBytes: 1. Byte : 1 (Start); 80h (Enter Pre-op) 2. Byte: Node ID (0:alle Knoten) Operational: SDO +PDOs aktiv Sync +Node-/Lifeguarding möglich NMT Master NMT Slaves(s) Byte 0 Byte 1 CS=80 Node-ID indication(s) COB-ID = 000

10 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 10 CANopen Geräteprofile Die CANopen Geräteprofile beschreiben das was der Kommunikation. In ihnen sind die Dateninhalte herstellerunabhängig festgelegt, die Grundfunktionalität der entsprechenden Geräteklasse (z.b. Ein- Ausgabebaugruppen, Servoantriebe oder Freqeunzumrichter) läßt sich also einheitlich ansprechen. Damit sind Geräte, die dem gleichen Geräteprofil folgen, untereinander austauschbar. Obwohl bereits viele optionale Parameter in den Profilspezifikationen beschrieben sind, bieten die Geräteprofile zusätzlich Raum für herstellerspezifische Funktionserweiterungen und sind damit future-proof. DS401 Digital Input

11 CANopen-Einführung Rüdiger Hambsch Elektronikschule Tettnang 11 DS401 Digital Output