AM2434: Ethercat PDO Input data delayed or missing

Part Number: AM2434

Hi, 

i have a problem with the ethercat subdevice / Beckhoff Slave example. My setup is the AM2434-LP running the  ethercat_subdevice_beckhoff_ssc... with industrial_comms_sdk_2025_0_0_8 and mcu_plus_sdk_11_1_0_19, directly connected over an ethernet cable to a dedicated laptop running twincat3. I use the TIESC-004 esi configuration with DC-Sync Mode and 1khz CycleTime. I overwrite the first input pdo entry with a simple 8bit counter as seen here:

void APPL_InputMapping(uint16_t *pData)
{
    uint16_t j = 0;
    uint8_t *pTmpData = (uint8_t *)pData;
    volatile static uint8_t testCounter = 0;

    for(j = 0; j < sTxPDOassign.u16SubIndex0; j++)
    {
        switch(sTxPDOassign.aEntries[j])
        {
            /* TxPDO 1 */
            case 0x1A00:
                *pTmpData++ = testCounter;
                break;

            case 0x1A03: // attention: maybe a non-aligned byte access...
                *pTmpData++ = sAI1Inputs.info1 & 0xFF;
                *pTmpData++ = (sAI1Inputs.info1 & 0xFF00) >> 8;
                *pTmpData++ = (sAI1Inputs.info1 & 0xFF0000) >> 16;
                *pTmpData++ = (sAI1Inputs.info1 & 0xFF000000) >> 24;
                *pTmpData++ = sAI1Inputs.info2 & 0xFF;
                *pTmpData++ = (sAI1Inputs.info2 & 0xFF00) >> 8;
                break;
        }
    }

    testCounter++;
}

This variable is linked inside twincat and logged via a measurement project. The plotted data shows delayed or missing counter values as seen in the attached images as red lines. The most data errors occour with the Master Sync ShiftTime of 10% and least with 40%.
What causes this and how can i fix this? Also this error only happens in dc-sync mode, freerun works without an issue.
Beckhoff_10%.pngBeckhoff_20%.pngBeckhoff_30%.pngBeckhoff_40%.png

Best regards

Lucas

  • Hi Lucas,

    Thank you for reaching out.

    I will review this and get back to you by EOD today.

    Meanwhile, can you share the wireshark log for this scenario?

    Regards,
    Aaron

  • Hi Aaron,

    thanks for the fast reply, here is the requested wireshark log.

    Regards,

    Lucas

    beckhoff_twincat_capture.pcapng.txt

  • Hi Aaron,
    do you have an update on the issue?

    Regards,
    Lucas

  • Hi Lucas,

    Apologies for the delay in response due to regional holidays.

    Thank you for sharing the logs. Here are my initial observations (which aligns with the plot):

    Filter: eth.src == 01:01:05:01:00:00 && ecat.cmd==lrw
    Total LRW frames captured: 132,996 (~125 seconds at 1ms cycle)

    What's happening

    The LRW data payload is 7 bytes: XX 00 56 34 12 e9 03 where the first byte is an incrementing counter (SubDevice's input PDO). It should increment by 1 every cycle.

    12 skip events were found. Each follows the same pattern:

    # Frame (skip seen) Timestamp Missing value Pattern
    1 15822 7.610s 0xe6 JUMP +2 then REPEAT
    2 27012 13.063s 0x33 JUMP +2 then REPEAT
    3 29804 14.426s 0x86 JUMP +2 then REPEAT
    4 48542 23.466s 0xd6 JUMP +2 then REPEAT
    5 49570 23.968s 0xcc JUMP +2 then REPEAT
    6 79744 38.496s 0x8c JUMP +2 then REPEAT
    7 100464 48.505s 0xa5 JUMP +2 then REPEAT
    8 106040 51.231s 0x4b JUMP +2 then REPEAT
    9 122997 59.409s 0x3d JUMP +2 then REPEAT
    10 137966 66.697s 0xb5 JUMP +2 then REPEAT
    11 189265 91.529s 0xb4 JUMP +2 then REPEAT
    12 258244 124.841s 0xd4 JUMP +2 then REPEAT

    Distinctive pattern at each event

    Normal:   ...prev-1  →  prev  →  X    →  X+1  →  X+2  ...
    Actual:   ...prev-1  →  prev  →  X+1  →  X+1  →  X+2  ...
                                  ^SKIP      ^REPEAT
                               (X never seen)
    

    The SubDevice's input PDO skips one value and then repeats the next value in the immediately following frame. 

    I will try to replicate this in our environment and run couple of tests.

    Follow-up questions regarding the issue:

    1. Can you mention if this is reproducible immediately or this happens after some duration (like hours, days or weeks)?

    Regards,
    Aaron

  • Hallo Aaron,

    thanks for the reply. The errors occur immediately at a rate of a bit under 0.01% so around 1 error every 10sec. I also tried adding the print lines in the tieschw.c with a baudrate of 12000000, to not slow it down to much. The print doenst show an error or to many so it seems its not reliable. 

    Are you able to reproduce my results?

    Regards
    Lucas

  • Hi Lucas,

    Are you able to reproduce my results?

    I haven't been able to reproduce the issue. I see that in my test environment, the counter is incrementing by 1 after every LRW read.

    I will share a debug firmware which you can test and let us know if the issue still persists. Give me some time to package the firmware.

    Regards,
    Aaron

  • Hi Aaron,

    where you able to package the firmware? I really love to see some working example before the weekend :)

    Best regards
    Lucas

  • Hi Lucas,

    I've shared the firmware offline.

    Regards,
    Aaron

  • Hi Lucas,

    Since the issue is not resolved with the latest firmware shared, I will try to reproduce the issue on my side.

    Firstly, I've implemented a counter as the first input PDO entry and enabled DC mode in TwinCAT at 1ms cycle time using the following steps: AM243x INDUSTRIAL COMMUNICATIONS SDK: EtherCAT SubDevice Setup with TwinCAT - Testing DC Synchronization mode.

    By reviewing the Wireshark logs for the LRW data from the SubDevice, I don't see any missed values.

    Is there any additional TwinCAT configuration you are doing prior to enabling the Run?

    The most data errors occour with the Master Sync ShiftTime of 10% and least with 40%.

    Is this an observation of the plotted graph or are you doing any additional step for Sync ShiftTime?

    Regards,
    Aaron

  • Hi Aaron,

    Further tests with a Beckhoff CX5140 as Master run without data issues. We initially used a laptop with 2 isolated cores, which works with our previous drive that uses OMAP + ET1100. Is there a reason why the pru tiesc that emulates the ET1100 functions is more prone to errors?

    Best regards,

    Lucas

  • Hi Lucas,

    Thank you for the clarification. In this case, I'm suspecting the presence of CRC Errors in the EtherCAT frames that can affect the triple buffer swap, thereby transmitting from a different buffer.

    Regards,
    Aaron

  • Hi Aaron,

    is there a way to verify this?

    Regards

    Lucas

  • Hi Lucas,

    You can monitor the Error counter registers (0x300 - 0x30C), specifically RX Error Counter and Forwarded RX error counter. You can also check the CRC error presence using a tap device, such as ET2000.

    Regards,
    Aaron