TPDOs are used to copy information from the Object Dictionary to the CANbus. The data being sent by the TPDO will appear on the CANbus as a series of CAN messages.
Each message on the CANbus consists of an 11-bit COB-ID3 and up to 8 bytes of data. When using the DVT, CAN messages can be seen to be scrolling up the CAN window.
TPDOs will repeatedly send CAN messages using a specific COB-ID. The system designer should assign a unique COB-ID for the TPDO to use. The message body used by the TPDO is able to store up to 8 bytes of data.
For example, I may wish to create a TPDO that sends out the following information:
The voltage read by the first analogue input, available from 0x6C01, 1
The speed of the local motor, available from 0x606C, 0
The statusword of the local motor, available from 0x6041, 0
From the Object Dictionary, we see that the analogue input voltage and statusword are 2 bytes each, and the local motor speed is 4 bytes, giving us 8 bytes in total. This should completely fill one TPDO.
In this example a COB-ID of 0x201 has been chosen as this will not interfere with anything else on the CANbus.
The data could be arranged in the CAN message as follows:
Figure 1 - Illustration showing formation of TDPO messages
The inverter can then be configured to send this CAN message repeatedly to the CANbus. The contents of the message will be updated, but it will always have a COB-ID of 0x201. Therefore it is possible for other nodes on the system to receive this data.
It is possible to configure up to 9 TPDOs on the inverter.
7.1. Defining the Contents of the TPDOs
The contents of each TPDO is defined in the Object Dictionary at locations 0x1A00. Objects 0x1A00 – 0x1A08 are supported by the inverter, a total of 9 possible TDPO. Each object has 8 sub-indices, meaning that each TDPO can have up to 8 items mapped into it.
Each of the mapping parameters is a 32-bit number. In the number, we encode the index, sub-index and length of each item that it to be mapped into the TDPO. The first 16-bits represent the index, the next 8 bits represent the sub-index and the last 8 bits represent the length of the object being mapped. These values are best expressed in hex.
In the above example of statusword, speed and analogue input value, we would set up the first TPDO mapping as follows:
Index Sub Index Value
0x1A00 0 0x03
3 COB-ID = Communication Object Identifier. This is the CANopen term for the CAN message identifier.
0x6041, 0 = 0x0027
1 0x6C010110
2 0x606C0020
3 0x60410010
The above objects define what information is to be sent in the TPDO. However it does not define what COB-ID the TPDO will use, or how often the data is to be sent. This is discussed in the next step.
7.2. TPDO Transmission Parameters
TPDO transmission parameters are defined in objects 0x1800-0x1808. The transmission parameters correspond to the TPDO contents that are defined at locations 0x1A00-0x1A08.
Each transmission type object has 5 sub-indices.
Sub index 1 defines the COB-ID of the TPDO. This is 32 bits long as it was designed to support the 29 bit COB-IDs available with CAN v2.0B. However, 29 bit COB-IDs are not used at present. This entry may also be set to 0x80000000, which will disable the TPDO.
Sub index 2 defines the transmission type. Set this to zero to have asynchronous TPDO transmission. In most
circumstances you would set it to a value between 1 and 240, to specify how many SYNC messages4 must be received before the TPDO is sent, so it is possible to specify the TPDO is sent, say, every 5th SYNC message. Setting this sub-index to 255 indicates the TPDO will be sent when there is a change to any of the values mapped to the TPDO.
Sub index 3 specified an inhibit time. For example, if the inhibit time is set to 10ms, the TPDO will never be sent more than once every 10ms. This is useful when the transmission type is set to 255, as it will prevent the CANbus being clogged with data from a sensor whose value may change many times in a short period
Sub index 4 does not exist on the inverter, or on many other CANopen devices. This sub-index is reserved for future use.
Sub index 5 is an event timer. A time in ms may be specified here. If a time is specified, then the TPDO will be sent on every time interval in addition to any other triggers that may exist. Set this sub index to zero to disable the event timer.
In the above example of sending the first TPDO using COB-ID 0x201 on every SYNC message, we would set the communication parameters as follows:
Some miscellaneous notes to bear in mind when setting up TPDOs:
TPDOs do not need to be acknowledged. There is no problem if a device is configured to send TPDOs and there are no other devices on the bus to do anything with these messages. In fact, this is a useful situation as it is common to find nodes with a set of TPDOs configured for use with monitoring tools such as the DVT which are not always connected.
The system must be in the pre-operational state in order to change any PDO mappings. In addition, sub index 0 of any of the mapping parameter objects must be set to zero before the mappings can be changed.
Changes to TPDO and RPDO mappings are not stored to EEPROM automatically. They will only be written to EEPROM when the store command is sent. To send the store command from the DVT, simply type ‘store’ and press return. If you key off before entering the store command you will lose your PDO setup.
A DVT script, pdo_config.tcl, is available as part of the DVT package. It sets up a default set of TPDOs that can be used when logging data with the DVT. Studying this script will provide more information on how TPDOs are configured.
4 SYNC messages are produced by the master node. They usually have a COB-ID of 0x80, but not always. The frequency at which SYNC messages are sent out can be adjusted in the Object Dictionary of the master node at index 0x1006.
Strictly speaking, you should only map objects which are read only to TPDOs. It is possible to map some which are read/write, but this may cause problems. For instance, when transmitting the state of digital inputs, it is better to transmit object 0x6800 than objects 0x21**.
CANopen data objects are written in the CAN packets in a little-endian form ie back to front.