Welcome to Ars-Informatica  

 
 
 
 
 
 

If you want to build a ship don't herd people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. (Antoine-Marie-Roger de Saint-Exupéry)

Overview


In CANOPEN each device in the network is called node. A maximum of 127 nodes can be attached to a network. CANOPEN standardizes the way the communicated data is structured and exchanged among these nodes. Each device/node can be any of the following: servo motors, sensors, generic I/O, encoders, drives, etc ...

Each node implements a specific Device Profile. These Device Profiles are well defined in the standard but CANOPEN allows such a freedom that it also supports building custom nodes and communication paths.

The core of any CANOPEN node is the Object Dictionary, a sort of lookup table with a 16-bit index and an 8-bit sub-index. This mechanism resembles PCI device space.

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.

To allow for peer-to-peer communication, CANOPEN introduces a node ID that gets embedded into the SDO requests to the object dictionary. This node ID must not be confused with CAN ID. They are related by a formula that is hereby explained. 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. Therefore node with node ID 1 has a can ID for RSDO messages 601h (standard can ID). 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.

How this data is organized is defined partially by the standard (mandatory entries) and by the device manufacturer.

In order for a generic tool understand the entire Object Dictionary the Electronic Data Sheets (EDS) is used.

Any manufacturer of a CANOPEN module delivers such a file with the module, which in layout is similar to the ".ini" files used on Microsoft Windows operating systems.

A CANOPEN master or configuration tool running on a PC with a CAN card can directly load the EDS into its set of recognized devices. Once a device is found on the network, the master or configuration tool will try to find the matching EDS. Once found, all supported object dictionary entries are known by the master / configuration tool.

With SDOs is possible to access any device entry.

Anyway during operation a better communication model is used that takes advantage of the multi-master concept behind CANOPEN standard.

This model uses PDOs: Process Data Objects.

A PDO is a "shortcut" to the process data in the object dictionary. Via PDO mapping (all done through object dictionary entries), any dictionary entry can be mapped to data in a PDO, to a maximum of 8 bytes per PDO.

As an example consider a CANOPEN input node that supports 2 digital inputs of 8-bits each and 2 analog inputs of 12-bits each. In conformance with the Device Profile for Generic I/O modules, an object dictionary entry at 6000h stores the 2 digital inputs of 8-bits each and an entry at 6401h stores the 2 analog inputs as 2 words.

The object dictionary entry at 1A00h specifies the PDO mapping - which bits of which object dictionary entries are used in the Transmit PDO 1 (TPDO1), filling the TPDO bit-by-bit. Note that this mapping can really be done on a bit-level. Each entry starts using the first available, free bit in the PDO and occupies as many bits as it requires.

The first sub-index entry at 1A00h maps object 6000h, sub-index 1, 8 bits to the first bits of the TPDO1. The next sub-index entry at 1A00h maps object 6000h, sub-index 1, 8 bits to the next free bits of the TPDO1, and so on. In this example the remaining bits of TPDO1 (data bytes 6-8) remain unmapped and unused.

Which PDOs are predefined and what default mapping is used is also specified in the Device Profile. If the mapping does not change during operation we call that static mapping. Dynamic mapping is the process of re-mapping a PDO during run-time.

A TPDO can be triggered in the following 4 modes:

  • Event driven: If the input device recognizes a change-of-state (COS) on any of its inputs, it updates the data in the object dictionary and the PDO and transmits the PDO. This mode allows for some of the fastest response times.
  • Time driven: A PDO can be configured to transmit itself on a fixed time basis, for instance every 50 milliseconds. This mode helps to make the total busload more predictable.
  • Polling: Using a regular CAN feature, the remote request frame, a PDO only gets transmitted if the data was specially requested by another node.
  • Synchronized: A special mode allowing for a synchronized polling as required by many motion control applications.

The counterpart of TPDOs are Receive Process Data Objects (RPDO). The default is that the master is the only node that receives Transmit Process Data Objects (TPDO). And only the master may send RPDOs to the slaves. In this way a pre-defined connection set is usable by default: an unique CAN message identifier is assigned to each supported PDO - one unique ID for each TPDO and one for each RPDO (pdo linking).

During the initialization and configuration cycle, the PDO linking can be changed. A master could inform one or multiple output modules that they should directly listen to a specific TPDO of an input module. Again, a TPDO correlates to a unique CAN message identifier. In this way a node is informed to which message frames it should listen to and which ones it can ignore.

Once these new linking settings are made and the network goes into the operational mode, the master would not need to get involved into the process data communication and could focus on other things like network management.