Embedded Networking with CANopen

By Olaf Pfeiffer

[ Select a Protocol  | HLP | Overview | Device Profiles | EDS | PDO | NMT | Implementing ]

The Object Dictionary Concept

The core of any CANopen node is the Object Dictionary, a lookup table with a 16-bit index and an 8-bit sub-index. This allows for up to 255 sub-entries at each index. Each entry can be variable in type and length.

All process and communication related information/data is stored as entries in pre-defined locations of the object dictionary. Unused entries do not need to be implemented.

Figure 1 Mandatory Object Dictionary Entries

From the network, object dictionary data of any node can be accessed in a point-to-point communication mode by issuing read or write requests to the node's object dictionary. Messages that contain requests or answers to/from the object dictionary are called Service Data Objects (SDO). As both process and configuration data are part of the object dictionary, this communication scheme immediately allows for configuring nodes and/or getting access to the process data.

Point-to-Point? Variable length? More than 8 bytes?

Those of you familiar with CAN probably have these questions after reading the previous paragraphs, as CAN itself does not really support these features - so how does CANopen do it?

Any message sent on CAN is a broadcast to all nodes. Which message IDs get used by which node is not part of the CAN specification and is usually determined by the application.

To allow for peer-to-peer communication, CANopen introduces a node ID that gets embedded into the SDO requests to the object dictionary. Each CANopen module on the network must have a unique node ID in the range from 1 to 127.

The default scenario is, that any node has two CAN identifiers reserved for SDO requests to and SDO replies from the object dictionary. The default CAN ID for the Receive Service Data Object (RSDO - used to send requests to a node) is a base address of 600h plus the node ID number. The ID for the Transmit Service Data Object (TSDO - used by a node to reply to requests) is a base address of 580h plus the node ID number. In this scenario, RSDOs may only be used by one node (usually the master, sometimes a configuration tool), to avoid conflicts/collisions arising from multiple nodes potentially trying to access a specific object dictionary at the same time.

The master or configuration tool can now scan for connected devices by sending 127 RSDO requests for the identity object - one to each potential node. All nodes present will respond with their TSDO containing the identification data from their object dictionary.

In case an object dictionary entry does not fit into one message (CAN has a limit of 8 bytes per message), the data transfer gets automatically fragmented. In this case, the first data byte is used as a control byte for handling the fragmentation. The remaining 7 bytes can be used for data transmitted with each fragment.

[ Select a Protocol  | HLP | Overview | Device Profiles | EDS | PDO | NMT | Implementing ]

Copyright © 2001 Circuit Cellar. All rights reserved.

ESAcademy, 2000

www.esacademy.com
info@esacademy.com