CANopen PDO only transmitted when ADI value is changed

We are facing an issue mapping multi-element ADIs to PDOs on our CANopen CompactCom B40 module. Specifically, in our ADI entry list, we have an ADI with data type ABP_UINT32 and length 2. This represents a 64-bit status register for our product. This ADI (#13) is mapped to a PDO write map as shown in the screenshot below, with two other ADIs (UINT32 length 1) in the next PDO write map. Our issue is that when we run our application, the second writemap’s contents is constantly being transmitted over the CANopen network as expected, but the first writemap’s contents are only transmitted when the value stored in the ADI changes. Since this first PDO/writemap corresponds to a status register, it only ends up being transmitted over CANopen when a user action or fault causes the status register to change on the host application. Shortening this ADI to be a single UINT32 type, we find that the PDO is constantly being transmitted without issue (but the data is truncated since we shortened the ADI to perform this test).

We have confirmed that our callback function is being regularly called and is updating the ADI’s stored value continuously, just as it is doing with our other two ADIs in the second writemap. The only difference as far as we can tell is that the ADIs that are working correctly have constantly changing values since they correspond to ADC measurements that have noise. The ADI that is not being transmitted still has its value updated by the callback function, it just does not change very often. It is also worth noting that the exact same code works with the EtherNet/IP CompactCom module without issue, and we see all 3 ADIs being transmitted as PDOs continuously. Any help in finding the source of this issue would be appreciated.

Hello @pdesai,

Sorry for the delay between traveling and the holiday I have neglected topics here.

How do you have the PDO’s configured in the master in particular the transmit type? It sounds like it may be Async.

Asynchronous: Triggered by an internal event (e.g. change-of-state of one of the mapped process data or elapsing of the event-timer or any other event). The device manufacturer specifies the internal event triggering the TPDO transmission.
PDO services

Do you still see issues if you use one of the other transmission types such as Cyclic synchronous?

Hi @deryck_hms,

Thank you for your response. Just to clarify: When you say master you are referring to the device connected to the Anybus module over the CANopen network, correct? In that case, yes, our generated EDS file has both TPDOs configured with transmission type 254, and the inhibit timers and event timers both set to 0. I was able to confirm this using SDOs to read back these values from the device.

I want to note that when debugging the host device firmware, we can see the callback function being called for all 3 ADIs in the writemaps and SPI data being transferred between the host device and the Anybus module constantly. This includes ADI 13 (the problematic array of 2xUINT32s).

I tried your advice and set the TPDO configuration parameters to be cyclic synchronous (set transmission type to 2 for the first writemap and type 1 for second writemap). Enabling syncing over the network gives expected results, with the first writemap being transmitted every 2 sync messages and the second writemap being transmitted for each sync message. Setting the transmission type back to asynchronous (254) and setting a non-zero event timer value also appears to work as expected.

These discoveries lead me to a new question: is there a way to pre-define these transmission parameters, or does this always need to be set by the network’s master after the device boots up? Ideally we would set this through the host device’s firmware so it does not need to be reconfigured all of the time.

Hi @pdesai,

This is the default mapping for the compactcom.