|
|
About CANopen |
Process data exchange with PDOs ("Process Data Objects") |
The main task of a CANopen system is of course the exchange of process data. For this, not only most of the CAN identifiers are provided but also most of the object dictionary entries. For the transmission of process data, this occurs without additional protocol overhead and transmission occurs according to the so-called "producer-consumer principle". This means that a message transmitted by a node (the "producer") can be received by all other nodes (the "consumers"). This principle is also referred to as "broadcasting" and represents a very efficient principle of data transmission, especially if a message (e.g. a synchronization message) is to be transmitted at the same time to all process participants.
A CAN message that contains process data is called PDO ("Process Data Object"). As already described, transmission of PDOs is only possible in the "Operational" state. PDOs have no fixed format. The data field of a PDO can be between one and eight data bytes long. The content of a PDO can also not be readily interpreted. The basic idea here is that both the transmitter and the receiver know how the content of a PDO is to be interpreted. For this reason it is sufficient to identify a PDO only by its COB-ID. The so-called "PDO mapping" describes which individual process variables in the data field of a PDO are transmitted, how they are arranged and which data type and length they have. Therefore the content and meaning of the data field of each defined PDO is described in the form of a PDO-mapping record inside the object dictionary both on the transmit and on the receive side.
The PDO producer composes the data field of a PDO in accordance with its TxPDO mapping. For this it takes the current data of the variables to be transmitted from its object dictionary and copies these into the data field of the PDO before the CAN message (PDO) is sent. The same happens on the consumer side: on the basis of the RxPDO mapping record, the data bytes of the received PDOs are copied into local object dictionary entries and thus generally device-specific actions are triggered (e.g. setting of digital outputs).
A network node that wants to accept a certain PDO must only activate the coresponding CAN message. This is done with "set valid" of the relevant COB-ID entry in the OD.
But now back to PDO mapping. The principle of the arrangement (mapping) of process variables is shown in the following (the variables are available in the form of object dictionary entries in the application profile). The mapping of the individual process variables in the data field of a PDO is described in the form of a table. This is also given as an object dictionary entry, namely for every transmit- and receive-PDO in [16xx] or [1Axx]. These tables, and therefore the mapping of the process variables in the data field of a PDO can be configured via SDO write accesses.
In this example there are exactly two object links: from object (process variable) [2345sub67] of the PDO producer to object [5432sub10] of the PDO consumer and from object [6000sub01] of the producer to object [6200sub02] of the consumer. The third transmit object, [2001sub00] is not evaluated on the receiver side and is therefore covered up with a so-called dummy object.
The mapping tables are of data type "PDO mapping", which contains in subindex 0 the number of mapped objects and in subindex 1 to 8 the mapped object dictionary entries themselves as DWORD. This contains the 24-bit long OD address (index, subindex) and the 8-bit coded length of the OD entry. A device that supports eight mapping entries has a granularity of 8 and can therefore only carry out "byte-wise mapping". Devices with a granularity of 1, on the other hand, support mapping of each individual PDO bit ("bit-mapping"). Accordingly there must then be 64 entries in the mapping table.
However, a PDO is described not only by mapping but also by its communication parameters. These are: COB-ID, i.e. identifier of the CAN message, "transmission type", "inhibit time", and can all be configured by a corresponding object dictionary entry. The position of this additional object dictionary entry has an offset of 0x200 before the associated mapping entry, i.e. for transmit PDOs [18xx] and for receive PDOs [14xx]. Each PDO is therefore described by two different OD entries, which firmly belong together and both must be configured by the system integrator. The following table shows the record "PDO parameter":
| Sub-Index | Contents | Data type |
| 0 | Largest sub-index supported | BYTE |
| 1 | COB-ID | DWORD |
| 2 | Type | BYTE |
| 3 | Inhibit time in ms | WORD |
| 5 | Event timer | WORD |
|
Subindex 1 contains the CAN identifier of the PDO right-adjusted in the double word. The highest value bit indicates whether the PDO is active (valid) or inactive (invalid). A set MSB means invalid, a value of 0x80000199, for example, describes an invalid first TxPDO of the node with the number 25.
The transmission type of a PDO can be set via the second subindex. First it is necessary to distinguish between synchronous and asynchronous PDOs:
| Value (dec) | Type |
| 0 | acyclic synchronous |
| 1...240 | cyclic synchronous |
| 241...251 | reserved |
| 252 | synchronous RTR only |
| 253 | asynchronous RTR only |
| 254...255 | asynchronous |
|
Asynchronous PDOs are event-controlled and represent the normal transmission type of PDOs. This means that when at least one of the process variables mapped in a PDO is altered, for example an input value, the PDO is immediately transmitted. For this, the values 255 or 254 are to be entered as PDO type.
Synchronous PDOs are only transmitted after prior reception of a synchronization message (Sync Object) . PDO transmission is thus carried out synchronously in the entire network, more or less at the same time. But what is much more important is that all device inputs must be sampled on the arrival of the sync object, so that a uniform snapshot of the process results. With the next sync-message, the recorded data are then sent in the synchronous PDOs. Therefore there is a delay here corresponding to the cycle time of the Sync message, as the consumers receive the process variables at the time of the previous Sync message. In output direction the synchronous PDOs received by a node only become valid on arrival of the next Sync message.
In order that the bus is not blocked up by a large number of synchronous PDOs, which are all sent with every Sync message, the values 1..240 of the cyclic synchronous PDO type are used as dividers for the transmission interval. Accordingly, [18xxsub02] = 4 means that the synchronous PDO is only sent with every fourth Sync message. Unaffected by this, the device must of course record its inputs with every Sync message, as it may happen that synchronously recorded process variables in a PDO are requested by RTR. In this case the CANopen device must transmit the corresponding PDO with the synchronously recorded values immediately. In [1006], the parameter "Communication Cycle Period", the nodes can be notified of the Sync interval in microseconds.
Finally, in subindex 3 an "inhibit time" can be set for asynchronous PDOs. The value is to be given as a multiple of 100 microseconds. The inhibit time is useful when frequent uncontrolled alterations of input values occur; e.g. with an open analog input. If the inhibit time is configured, the node may not transmit the relevant PDO again before expiry of the inhibit time; this ensures that there is no inadmissibly high busload due to a so-called "babbling idiot". The inhibit time is only used for TxPDOs, of course. It has no significance for RxPDOs.
Asynchronous TxPDOs can be transmitted cyclically with the event timer, subindex 5. If its value is greater than 0, it becomes a millisecond timer. When this is expired, the PDO is transmitted. Transmission therefore takes place both when an external device input is altered and when the event timer is lapsed. This subindex is also only significant for transmit-PDOs.
A CANopen node usually has four transmit-PDOs and four receive-PDOs, where one COB-ID is reserved for each of these PDOs. This therefore occupies a total of 127*4*2 = 938 COB-IDs, i.e. almost half of the entire identifier space. However, due to the so-called "object linking", i.e. the establishing of communication relationships between a transmit- and a receive-PDO, CAN identifiers become free again, as with linking either the producer or the consumer must adapt its COB-ID to those of the communication partner and it's own reserved COB-ID thus becomes free. Therefore, in practice, for a network with 127 network nodes, an average of eight COB-IDs are available per device for TxPDOs. For networks with a lower number of network nodes, the unused COB-IDs can also be used of course. The system integrator must always have an overview of the allocation of the identifier space and the COB-IDs actually in use; for more complex systems, a software tool - e.g. IXXAT CANopen ConfigStudio, is recommended. This tool, for example, handles PDO-mapping and -linking automatically.
|
 | |
|