Embedded Networking with CANopenBy Olaf Pfeiffer [ Select a Protocol | HLP | Overview | Device Profiles | EDS | PDO | NMT | Implementing ] |
|
|||||||||
|
Increased Performance with Process Data ObjectsSo far, we structured the configuration and process data in a way, that a master could easily access it. From the process point of view, the following operating mode would be possible: polling all inputs, work on the data and then write to all outputs. For most applications, this would not be an efficient communication model. As CAN supports the multi-master concept (any node could send a message at any time, collisions are resolved by ID priority), we can expect a more direct, higher priority access to the process data. PDO mapping A Process Data Object (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. Let's have a look at the example of figure PDO Mapping: A CANopen input node 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. Obviously, dynamic mapping is more complex and adds more overhead to the PDO processing time. PDO triggering Now that we have a shortcut to several dictionaries entries in one message, what are our options to trigger a PDO? CANopen supports a total of 4 trigger modes:
PDO linking When it comes to the communication partners involved, we have a similar arrangement as with the SDOs. The default is that the master is the only node that receives Transmit Process Data Objects (TPDO). And only the master may send Receive Process Data Objects (RPDO) to the slaves. In other words, we ensure that a pre-defined connection set is usable by default, as we assign unique CAN message identifiers to each supported PDO - one unique ID for each TPDO and one for each RPDO.
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. So we basically just inform a node to which message frames it should listen 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.
[ Select
a Protocol | HLP | Overview
| Device Profiles | EDS | PDO
| NMT | Implementing ]
|
ESAcademy, 2000 All materials |