MPDO – Multiplexed Process Data Objects
The MPDO service can be uses – such as normal PDOs – to exchange process data between multiple CANopen devices. It also uses the Producer-Consumer model, so that an MPDO may be received by multiple consumers. In contrast to PDOs the object to be transmitted is not defined in a mapping table, but index and subindex of the object are transmitted as well. Thus the payload for MPDOs is reduced to only 4 bytes and only one object can be transferred in a single message. Unfortunately, not all CANopen devices support the MPDO service. If the EDS file contains the entry GroupMessaging=1 MPDOs are supported.
The configuration of COB-ID and transmission type is done in the same way as with normal PDOs in the corresponding objects in the object dictionary starting at 0x1400 or 0x1800. MPDOs may only be transmitted event-driven, so the possible transmission types are limited. Additionally, there is a object scanner list and a object dispatcher list to configure the MPDOs.
Source Address Mode
As the name suggests the node-ID of the producer and the index and subindex at the producer are transmitted in the MPDO.
The scanner list (starting at index 0x1FA0) in the producer defines which objects may be sent by MPDO. The dispatcher list in the consumer (at index 0x1FD0) defines, which transmitted object shall be copied into which object at the consumer.
The dispatcher list contains of several 64-bit values and each sub index represents a producer – consumer object assignment.
|63 .. 56||54 .. 40||39 .. 32||31 .. 16||15 .. 8||7 .. 0|
|Block Size||Local Index||Local Subindex||Producer Index||Producer Subindex||Producer Node|
Structure of 64-bit entries in dispatcher list
The “MPDO Linking” works as shown in below:
Destination Address Mode
Using the destination address mode the producer can specify to which object of the consumer the value shall be written.
Additionally, it is possible by specifying the target node ID 0 to send a broadcast message to all nodes. In this case the value is written into the same index/subindex at all nodes that receive this MPDO.
Comparision with SDOs and PDOs
Analyzing MPDOs in CAN logging
To analyze MPDOs in a CAN logging a tool with CANopen interpretation should be used. It is important to check in advance, if this tool also supports MPDO interpretation. It must be possible to import EDS or DCF file of all devices in the network in order to interpret the MPDOs correctly.
The emotas’ CANopen DeviceExplorer is such a tool and the screen shot below shows the MPDO interpretation:
Use cases for MPDOs
A CANopen device may send up to 512 normal PDOs. Considering that an object only has 1 byte, it is possible to send up to 4096 different objects from a device. In a real application this values is smaller, because there are multiple devices in a network and the data are often greater than 1 byte. Using MPDOs there is no limitation on the number of different objects.
In CANopen the MPDO service is optional, but in some application profiles such as CiA-417 (CANopen Lift) it is required.
Availability in devices and stacks
As MPDOs are optional it is not implemented in all CANopen devices. In reality most CANopen devices do not support MPDOs.
Both know open source CANopen implementation to not support it as well, but there are some commercial vendors of CANopen Stacks that support MPDOs in their CANopen Stack or CANopen Software.