Introduction To The CANopen Protocol

1 Introduction To The CANopen Protocol Version Application Note AN-ION-1-1100 Restrictions Public Document Abstract This application note is a brief Introduction to the Higher-Layer CAN Protocol called CANopen . Table of Contents Copyright 2003 - Vector Informatik GmbH. 1 Contact Information: or 1-248-449-9290 1 Overview ..1 History ..2 Highlights ..2 2 Standardized Structure ..2 3 The Device Model ..4 4 Physical Layer ..4 5 The Object Dictionary ..4 6 Communication Channels ..5 7 Network 8 Pre-Defined Connection 9 CANopen System Configuration ..8 10 Device Profiles ..9 11 Conclusion ..9 12 1 Overview CANopen is a "Layer 7" CAN Protocol that defines communication and device functions for CAN-based systems. CANopen is a standardized, highly flexible, and highly configurable embedded network architecture used in industries such as Railway, Medical, Industrial, Agriculture, Heavy Truck & Bus, Marine, Off-Highway, factory automation , Aerospace, and many others.

2 CANopen is also becoming a popular choice for closed, company-specific embedded networks. The CANopen profile family specifies standardized communication mechanisms and device functionalities. The CANopen Standard is maintained by "CAN in automation (CiA) International Users and Manufacturers Group" and can be implemented without a license. Introduction To The CANopen Protocol Application Note AN-ION-1-1100 2 History 1992 (Jul) Start of ESPRIT III Project ASPIC. CAN selected as a suitable field bus system. Start of communication and device profile development. 1994 (Jun) Profiles handed over to the CAN in automation (CiA) international users and manufacturers group. 1994 (Sept) First implementations outside ASPIC. 1995 (Feb) The standard is given the name " CANopen ".

3 1995 (Apr) CANopen robot cell shown at HMI. 1995 (Oct) Communication profile DS-301 available. 1996 (Feb) First device profile (DS-401) was available. 1996 (Apr) Multi-vendor system shown at HMI. 1996 - 1997 Development begins on several device profiles and a Framework for Programmable Devices (WD-302). 1999 (Jun) The DS-301 submitted for European Standardization. 2001 The European standardization authorities accept CANopen version as EN 50325-4. Present Many device profiles and frameworks are available. Hundreds of implementations in the worldwide market. Highlights CANopen Protocol characteristics: Open architecture Real-time transfer of process data without Protocol overhead Modular and scalable Interoperability and interchangeability Profile concept similar to Interbus-S and Profibus Supported by many international manufacturers CANopen allows: Standardized configuration of networks Access to all device parameters Synchronization Cyclic and event-driven process data transfer combined with asynchronous domain transfer 2 Standardized Structure Compared to the ISO/OSI Stack, CANopen is a "Layer 7" communication profile based on CAN, which is standardized in ISO 11898.

4 It is supplemented by a set of device profiles. The CiA manages the documents. The main document is the "CiA DS 301 - CANopen Application Layer And Communication Profile" (EN 50325-4). It describes all basic principles, data types, encoding rules and services. Introduction To The CANopen Protocol Application Note AN-ION-1-1100 3 Figure 1 The ISO OSI Stack The following set of papers supplement the DS-301 (there are more): CiA DSP-306 - CANopen electronic data sheet (EDS) for CANopen CiA DSP 302 - CANopen framework for CANopen managers and programmable CANopen devices CiA DSP 305 - CANopen layer setting services and Protocol (LSS) CiA DR 303-1 - CANopen cabling and connector pin assignment A series of device, application, and interface profiles complete the specification.

5 Figure 2 CANopen Documents Introduction To The CANopen Protocol Application Note AN-ION-1-1100 4 3 The Device Model A unified view of CANopen devices requires the use of a general device model so that different devices can be described by one standard. The device model consists of three main components: Communication Object Dictionary Application Figure 3 CANopen Device Model 4 Physical Layer The physical medium for CANopen devices is a differentially driven two-wire bus line with common return according to the ISO 11898 standard. The CANopen standard does not mandate a specific Physical Layer, which allows CANopen to be used in specific environments. CANopen does however provide a set of recommendations and specifications for industrial use. CiA DR 303-1 defines pin assignments for many connectors, such as the 9-pin D-sub connector (DIN 41652 or corresponding international standard), the 5-pin mini style connector, the open style connector and the multi-pole connector.

6 5 The Object Dictionary CANopen is built around the central concept of an Object Dictionary (OD), the interface between the application and communication within each device. Every function, variable and data type seen via the network must be described in the OD. Object Dictionary characteristics include: Collection of communication and application-relevant parameters Standardized structure Access to structured parameters (arrays, records) Reference to data types In order to allow access to all entries, the OD defines a standard addressing scheme where each object has an index. The index is a 16-bit offset into the OD. There is direct access to non-structured objects like Boolean, Unsigned32, etc. Main Index Variable Accessed Data Type 1000H Device Type Unsigned32 Table 1 Object Dictionary Standard Addressing Scheme From a programmer s point of view, this is equivalent to: Introduction To The CANopen Protocol Application Note AN-ION-1-1100 5 unsigned long DeviceType; Structured data types use an 8-bit sub-index to denote a field inside a structure or array.

7 Main Index Sub Index Variable Accessed Data Type 6092H 0 Number Of Entries Unsigned8 1 Baud Rate Unsiged16 2 Number Of Data Bits Unsigned8 3 Number Of Stop Bits Unsigned8 4 Parity Unsigned8 Table 2 Array And Structure Indices From a programmer s point of view, this is equivalent to: typedef struct { unsigned char NumberOfEntries; unsigned short BaudRate; unsigned char NumberOfDataBits; unsigned char NumberOfStopBits; unsigned char Parity; } RS232; RS232 rs232; The indexes are organized in several index ranges: Index (hex) Object 0000 not used 0001-025F Data Types 0260-0 FFF Reserved for further use 1000-1 FFF Communication Profile Area 2000-5 FFF Manufacturer Specific Profile Area 6000-9 FFF Standardized Device Profile Area A000-BFFF Standardized Interface Profile Area C000-CFFF Reserved for further use Table 3 Pre-defined Index Ranges 6 Communication Channels The basic communication mechanisms are categorized as one of the following relationships: Client / Server - Point-to-point connection.

8 The client always takes the initiative (N Clients, n Servers) Master / Slave - Point-to-point connection. The Master always takes the initiative (1 master, Client Servers) Producer / Consumer - This broadcast connection is exactly like the CAN Protocol s broadcast capability. The Producer takes the initiative during the unconfirmed relationship. The Consumer takes the initiative during the confirmed relationship (N Producers, M Consumers) The two most important communication types are the Process Data Object (PDO) and Service Data Object (SDO): Introduction To The CANopen Protocol Application Note AN-ION-1-1100 6 Process Data Object PDO High priority real-time data exchange Broadcast Non-acknowledged No Protocol overhead Synchronous / asynchronous, cyclic/ acyclic, event driven transmission Maximum 8 bytes of data Service Data Object SDO Access to object dictionary Peer-to-peer communication Acknowledged service Low priority Transfer of domains The PDO is used for normal process data communication, the primary purpose of the CANopen network.

9 The SDO is used for configuration and diagnostic access to a device. It is not as fast as PDO, but provides the most flexible means to read/write any amount of data. CANopen defines additional communication objects for real-time usage, such as TIME and SYNC. 7 Network Management A CANopen network requires a Network Management (NMT) Master and all NMT Slave devices to implement a state machine. The NMT Master controls the status of all the NMT Slaves on the network. After "power-on" and internal initialization, the NMT Master automatically brings every Slave device into the "Pre-operational" state. Each Slave device may be configured and parameterized via SDO ( , Master or configuration tool), but no PDO communication is allowed at this state. Now the NMT Master may switch all nodes (or a single node) to their "Operational" state.

10 In the "Operational" state, all communication objects are active. Switching a node into a "Stopped" state terminates all PDO and SDO communication. Introduction To The CANopen Protocol Application Note AN-ION-1-1100 7 Figure 4 NMT State Machine CANopen has two alternatives for protecting the existence and status of the state machine: the Heartbeat and Guarding protocols. The Heartbeat Protocol is only used in modern system designs. CANopen devices have signal error conditions, such as "Voltage low", for when an event occurs instead of having to be polled from a Master. The Emergency (or EMCY) message contains standard and profile-specific error codes. Figure 5 Heartbeat Introduction To The CANopen Protocol Application Note AN-ION-1-1100 8 8 Pre-Defined Connection Set Client/Server and Producer/Consumer connections can be set-up dynamically by configuring the Object Dictionary.