CANopen and Kvaser

CANopen uses different communication models for message transmission between nodes:

Producer/Consumer model: it is a broadcast connection and works in push mode (producer node sends information to the consumer node without any specific request) and pull mode (consumer node requests specific information from the producer node).

Client/Server model: uses the SDO protocol by which client node requests data (object dictionary index) from the server node and the server node then responds by sending the object content at the specified index.

Master/Slave model: the master node can send to or request data from slave nodes any time. Eg: NMT protocol communication.

CANopen communication unit consists of necessary communication interfaces and protocol software to provide transmission and reception of communication objects through the bus between nodes. Different CANopen communication objects are used for implementing various types of communications like process data, network management, node monitoring, synchronization signals error control and emergency messages. These objects and their description are listed in the table to the right.

Example entries for Communication Profile

Example of sub indexes for referencing complex or structured data type entries

The entries are for a single channel RS-232 interface, that may have its communication parameters exist as a single structured data type at index 6092H. The individual communication parameters then exist in sub indexes of 6092H, and ranges from 0.

The C programming language structure definition for above object dictionary entries is:

The CANopen network management uses the Master/Slave communication model. The entire network is implemented as a “state machine” in which, one device is designated as the NMT Master and other devices as NMT Slaves. The NMT master controls and monitors the states of the NMT slaves. The NMT slaves go through state transitions triggered by the NMT master to enter into various phases of CANopen network implementation. 

The state change commands are issued from the Master to the Slave(s) for these state transitions using specific NMT protocols like the Bootup Protocol, Module Control Protocol, Heartbeat Protocol and Node Guarding. The NMT master sends NMT command codes to specific node(s) or all nodes to change state.

The initial state transition sequence of the NMT Slave state machine starts from Power-On or a recovery from Power-Off events followed by device Initialization. The NMT slave devices will then automatically make transition into the Pre-Operational state. The Internal Device Reset (Reset Application and Reset Communication) event during error control and diagnostics also will take the NMT slave devices into the Initialization state followed by the Pre-Operational state. Before this transition, the devices will transmit a boot-up message into the bus using the Boot-Up protocol to indicate the boot-up process.

In the Pre-Operational state, the application configuration tool can configure and parameterize the NMT slaves using SDO communication. Since the devices are not yet operational, no PDO communication is allowed at this state. 

Once the state is changed from Pre-Operational to Operational, all the communication objects in the nodes become active and both PDO and SDO communications are allowed between operational nodes. During this stage object dictionary access through SDO is also possible. Both PDO and SDO communication are stopped once the node state is changed to Stopped. 

The NMT master regularly polls slave devices with a remote frame to retrieve their current state and matches those with the earlier states recorded in the network database. Any mismatches and absence of PDO transmission are indicated with appropriate error codes and the application will take appropriate actions like device reset or error indication. This is called Node Guarding and is implemented using the Node Guarding Protocol. NMT slaves use a technique called Life Guarding to detect the absence of NMT master by checking internally for reception of Node Guarding frames in pre-defined time intervals.

Modern device designs use the Heartbeat Protocol for node monitoring in which the NMT slave (the Heartbeat Producer) will cyclically send Heartbeat Messages to the NMT master (Heartbeat Consumer). The interval between these messages is configurable and set in the Heartbeat producer time object in object dictionaries of both devices. If the Heartbeat message does not arrive within this time limit, the producer will be considered as down and consumer takes remedial actions like device reset or error indication.

For simple communication structures with exactly 1 master and upto 127 slaves, CANopen provides pre-defined allocation of CAN message identifiers called Pre-Defined Connection Set. The overall aim of this scheme is to reduce the configuration overhead in simple networks that need peer-to-peer connections only. This pre-defined master-slave connection scheme supports communication object allocation as follows per device:

• One Emergency object
• SYNC and TIMESTAMP objects
• One SDO connection 
• NMT for node monitoring (node guarding/heartbeat)
• Upto 4 transmit and 4 receive PDOs

An Electronic Data Sheet (EDS) is a standardized electronic file that describes the communication functionality and objects defined for the CANopen device. This vendor generated file has 3 areas:

• Information about the EDS file
• General device information 
• Object dictionary with default values

The EDS file can be used as a tool for configuration and network setup for CANopen devices.