CAN CANopen

History 1986 Robert Bosch GmbH introduced CAN protocol at the Society of Automotive Engineers (SAE) congress 1987 First CAN controller chips from Intel and Philips Semiconductors Epec 2G CAN Modules in 1991

CAN Controller Area Network Standardized serial bus protocol ISO 11898-1 (CAN Data Link Layer and Physical Signaling) Use automotive applications industrial automation medical equipment

CAN and ISO/OSI model CAN protocol defines following OSI layers Data link (OSI 2) Physical (partly) (OSI 1)

CAN physical layer standards ISO 11898-2 high speed the most used physical layer standard for CAN networks implemented as CAN high-speed the data rate up to 1 Mbit/s

CAN physical layer standards ISO 11898-3 fault-tolerant baud rate < 125 kbit/s for this specification a short network was assumed, the problem of signal reflection is not as important as for long bus lines

CAN physical layer standards SAE J2411 single wire for CAN network applications with low requirements regarding bit rate (33,3 kbit/s) and bus length ISO 11992 point-to-point defines a point-to-point connection for use in e.g. towing vehicles and their trailers

Some terms COB-ID Communication Objects (COB) are uniquely identified in a CAN network by a number called the COB-ID. The COB-ID also determines the priority of the object. NODE-ID Unique ID number of a device in CANopen network EDS Electronic data sheet describes the communication behaviour and the object dictionary entries of a device Allows service tools, configuration tools, development tools, and others to handle the devices properly DCF Device configuration file almost identical to the EDS stores the configuration parameters of a specific node can include minimum, maximum and default values for each entry

CAN basic concept Two communication services Broadcast Communication the sending of a message the requesting of a message Broadcast Communication All CAN nodes can receive all messages on the CAN bus After receiving a message, the node decides if the message has to be accepted or not

CAN basic concept CAN frame formats Standard, 11-bit identifier field Extended, 29-bit identifier field The 11-bit message always has priority over the 29-bit message The implementation must accept the base frame format The extended frame format must be at least tolerated

Standard/extended frames

CAN Frame Types Data frame carries the data from a transmitter to the receivers Remote frame is a frame requesting the transmission of a specific identifier Error frame is transmitted by any unit on detecting a bus error Overload frame is used to provide for an extra delay between the data and/or remote frame

Higher layer implementations As the CAN standard does not include tasks of application layer protocols, such as device addressing transportation of data blocks larger than one message application data implementations of higher layer protocols were created

CAN protocols CANopen (www.can-cia.org) SAE J1939 (www.sae.org) Industrial automation SAE J1939 (www.sae.org) Heavy road vehicles ISOBUS (www.isobus.net) Agriculture DeviceNet (www.odva.org)

CANopen

CANopen CAN-based higher layer protocol for distributed automation systems Standardized (EN 50325-4) Specifies communication protocols (NMT, SDO, PDO etc) device profiles (CiA 401, 402, 405..) for typical devices of distinctive application areas

CANopen is used Machine control Factory automation Laboratory automation Transportation and traffic Utility vehicles Building automation Medical Systems

CANopen benefits Guarantees an interchangeability of devices Enables the communication between devices of different manufacturers Standard features Transmission of time-critical process data Device description in OD Device monitoring Error signaling Network management Pre-defined connection set

CANopen internal device structure A CANopen device can be logically structured in three parts

CANopen internal device structure

OD = Object Dictionary OD is the most important part of any CANopen device The interface between the application and CAN bus Grouping of objects (parameters) accessible via CAN in an ordered and pre-defined way Addressed with index and sub-index

OD = Object Dictionary Each CANopen device implements a CANopen protocol stack Usually implemented on the same micro-controller that is used by the device's application software

OD layout Index range Use Description 0000h Reserved 0001h – 025Fh Data types 0260h - FFFh 1000h - 1FFFh Communication object area Describes the communication behavior of the device 2000h - 5FFFh Manufacturer specific area Describes the application behavior in a manufacturer specific way 6000h - 9FFFh Device profile specific area Describes the application behaviour in a standardized way by following a CANopen device or application profile A000h - BFFFh Interface profile specific area Defines the network variables and system variables according to the related CiA interface specification C000h – FFFFh

Node identification All nodes are uniquely identified by node identification number Node-ID value range is 1-127 CANopen systems can have 127 different nodes No node-ID may exist twice

Master/Slave relationship Every CANopen system has to have one Master node Master unit typically can Start or stop the network Monitor the network There can be multiple slaves in system Normally the only special function of the CANopen Master is the starting of the network

Communication protocols Process Data Objects (PDO) protocol Service Data Objects (SDO) protocol Network Management (NMT) protocols NMT Message protocol Boot-Up protocol Error Control protocol Special Objects protocols Synchronization (SYNC) protocol Time Stamp (TIME) protocol Emergency (EMCY) protocol

Process data objects (PDO) Used for broadcasting high-priority control and status information Consists of one CAN frame  8 bytes of data Communication: point to multipoint

Process data objects (PDO) Triggering PDOs Event or time Synchronous/asynchronous transmission Remotely requested (RTR) The PDO consumer must know what PDO to receive and what bytes contains the needed data

Predefined connection set CANopen standard defines a pattern for message identifiers 1st PDO COB-ID = 180h + node-ID 2nd PDO COB-ID = 280h + node-ID 3rd PDO COB-ID = 380h + node-ID 4th PDO COB-ID = 480h + node-ID

Service data objects (SDO) Service data objects (SDOs) enable access to all entries of a CANopen OD The communication is point-to-point The basic idea is that the SDO client sends request and the SDO server responses to the request

Special protocols The SYNC object enables synchronous network behavior. Synchronous PDOs use the SYNC message as triggering event for PDO transmission The TIME, Time-stamp, object is used for the adjustment of a unique network-time The EMCY, Emergency, object can be used to inform other network participants about device-internal errors 

Network management (NMT) CANopen provides services and protocols for controlling of the communication state of the nodes monitoring nodes The network management Master can control the communication state of the other nodes with NMT messages NMT messages has the highest priority message identifier (CAN-ID 0)

Network management (NMT) The NMT message consists of two bytes: The command byte (start / stop/ …) The node-ID whose communication state is to be changed  COB-ID BYTE 0 / CMD BYTE 1 /NODE-ID  000 0x01 Start 0x00 (All) 0x02 Stop 0x01 (Node-ID 1) 0x80 Preoperational … 0x81 Reset node 0x7F (Node-ID 127) 000 0x82 Reset communications

NMT states and transitions

Network management (NMT) The NMT state machine defines the communication behavior of the CANopen device State NMT SDO PDO Init - Pre-Operational x Operational Stopped

CANopen device monitoring Heartbeat principle a node automatically transmits its communication state (NMT) at regular intervals as evidence of its communication ability Transmitted cyclically with COB-ID = 0x700 + node-ID Recommended by CiA (node guarding is no longer used)

Predefined connection set Communication object COB-ID (hex) Slave nodes NMT Receive only SYNC 80 EMCY 80+NODE-ID Transmit TIMESTAMP 100 PDO 180+NODE-ID 1. Transmit PDO 200+NODE-ID 1. Receive PDO 280+NODE-ID 2. Transmit PDO 300+NODE-ID 2. Receive PDO 380+NODE-ID 3. Transmit PDO 400+NODE-ID 3. Receive PDO 480+NODE-ID 4. Transmit PDO 500+NODE-ID 4. Receive PDO SDO 580+NODE-ID 600+NODE-ID Receive NMT node monitoring 700+NODE-ID

Basic OD entries Index Sub-index Type Description 0x1000 U32 Device type 0x1008 STRING Manufacturer device name 0x1009 Manufacturer HW version 0x100A Manufacturer SW version 0x1010 Store parameters (”save”) 0x0 U8 Number of entries 0x1 Save all parameters 0x2 Save communication parameters 0x1011 Restore default parameters (”load”) Restore all default parameters 0x1016 Consumer heartbeat time 0x1 – 0x7F 0x1017 U16 Producer heartbeat time

Basic OD entries Index Sub-index Type Description 0x1018 Identity object 0x0 U8 Number of entries 0x1 U32 Vendor-ID 0x2 Product code 0x3 Rev. Number 0x4 Serial number 4G communication parameters (2020, 2023, 2024, 2038) 0x2003 Node-ID for CAN1 Bit rate for CAN1 0xD Node-ID for CAN2 0xE Bit rate for CAN2

Basic OD entries 3000, 4602, 5050, i10, 6000 communication parameters Index Sub-index Type Description 0x2150 CAN1 configuration 0x0 U16 Number of entries 0x2 CODESYS communication node-ID 0x3 Bit rate 0x4 Cable detection offset for CODESYS node-ID 0x5 Cable detection offset for PLCopen node-ID 0x6 Mask for the cable detection pins 0xA PLCopen application node-ID in CAN1 0x2151 CAN2 configuration (if exists, see sub-indexes above) 0x2152 CAN3 configuration of 5050, see sub-indexes above 0x2153 CAN4 configuration of 5050, see sub-indexes above

Source CAN in Automation CiA Standards 301 & 302 www.can-cia.org http://www.can-cia.org/fileadmin/cia/specifications/CAN20B.pdf CiA Standards 301 & 302 IXXAT http://www.canopensolutions.com/english/about_canopen/about_canopen.shtml Wikipedia: CAN, CANopen