• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1079 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3357: EtherCAT errata PINDSW-141

Kuerbis
Expert 4145 points
Part Number: AM3357

Hi Team,

 

If LRD/LWR option is enabled on SOEM v1.3.3 (Master), all salve access has to be LRD/LWR. The customer thinks It becomes inefficient to use LRD/LWR.

 

In the case of SOEM's method of using LRW, the efficiency is poor in fact. Do you have the data that there is almost no difference in efficiency even if LRD / LWR is used instead? I'd like ask you to create a document (preferably measured data) for it.

 

The following topology is preferred for the data.

SOME > Slave1 > Slave2 > Salve3

 

The errata say that this issue will not be fixed.

Do you still no plan to fix it?

Thanks and Best regards,

Kuerbis

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 43296 points
    Kuerbis,

    In addition to the LRD/LWR workaround, the errata also suggests to continue using LRW datagram to access process data but ensure
    •Input and output overlaid on the same logical address range (TwinCAT usage)
    •Input and output of a given slave back to back in logical address space
    – FMMU0(0x1000:0x1007)->SM2 #1(Write SM) FMMU1(0x1008:0x100F)->SM3#1 (Read SM)
    – FMMU2(0x1010:0x1017)->SM2 #2 (Write SM) FMMU3(0x1018:0x101F)->SM3#2 (Read SM)

    We have limited experience on SOEM, would it be possible to adjust SOEM FMMU/SM configuration as described above?

    We don’t plan to fix PINDSW-141 as it is explained in the errata – to cover the use case requires more code memory which is very limited in AM335x, and the non-interleaved I/O data access is not optimal, which increase the cycle time overhead.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    TI__Mastermind 43296 points

    Kuerbis,

    PINDSW-141 is covered in SOEM v1.3.3 - ec_config_overlap_map(), see the SOEM code comment below:

    --------------------------

    /** Map all PDOs from slaves to IOmap with Outputs/Inputs
    * in sequential order (legacy SOEM way).
    *
    * @param[out] pIOmap = pointer to IOmap
    * @return IOmap size
    */
    int ec_config_map(void *pIOmap)
    {
    return ec_config_map_group(pIOmap, 0);
    }

    /** Map all PDOs from slaves to IOmap with Outputs/Inputs
    * overlapping. NOTE: Must use this for TI ESC when using LRW.
    *
    * @param[out] pIOmap = pointer to IOmap
    * @return IOmap size
    */
    int ec_config_overlap_map(void *pIOmap)
    {
    return ec_config_overlap_map_group(pIOmap, 0);
    }

    Regards,

    Garrett

  • 0 in reply to Garrett Ding
    TI__Expert 4145 points

    Hi Garrett

     

    Thank you for investigation this.

    We asked to the customer if this issue could be fixed by the ec_config_overlap_map().

    I’ll get back to you once we receive the feedback from the cuatomer.

     

    Best regards,

    Kuerbis

  • 0 in reply to Kuerbis
    TI__Mastermind 43296 points
    Hi Kuerbis,

    Should we close the ticket?

    Thanks,
    Garrett
  • 0 in reply to Garrett Ding
    TI__Expert 4145 points

    Hi Garrett

     

    Let’s close this once due to I didn’t receive any issue report so far.

    I’ll make the related question if they still have an issue while testing it.

     

    Best regards,

    Kuerbis