• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 307 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.

AM2612: Ethercat SyncManager three buffer mode and recommendations to minimize potential synchronization latency

Gunter Schmer
Genius 14412 points

Part Number: AM2612

Tool/software:

Hi all,

one of our customers is using the AM2612 for an Ethercat subdevice CiA402 control application. Additionally there are other off-the-shelf (OTS) actuators in play. During testing of the OTS actuators the customer observes unexpected synchronization latency in the cyclic process data, and the customer believes this is related to the SyncManager three-buffer-mode in that case.

They are concerned and wanted to proactively inquire about the AM261x implementation of the syncmanager three-buffer-mode, specifically the expected behavior of the implementation of the ESC, and recommended potential configuration optimizations to minimize this delay.

Regards,

--Gunter

  • 0
    TI__Guru 51141 points
    Gunter Schmer said:
    During testing of the OTS actuators the customer observes unexpected synchronization latency in the cyclic process data,

    Based on our offline discussion - this is Beckhoff IP based and most likely I suspect this is a usage issue. 

    Gunter Schmer said:
    and the customer believes this is related to the SyncManager three-buffer-mode in that case.

    Can they share detailed wireshark logs or any other supporting data to explain the problem in detail.

    Gunter Schmer said:
    AM261x implementation of the syncmanager three-buffer-mode, specifically the expected behavior of the implementation of the ESC, and recommended potential configuration optimizations to minimize this delay.

    We have other customers in this past evaluate this feature on TI ESC and this is all assuming the SubDevice is running in DC mode and readings we get for 1ms cycle time is shown below vs theoretical expectations

    1) PLC to SDevice-> ~0.3 cycle (Rx PDO)

    2) SDevice to PLC -> ~1.7 cycles (Tx PDO)

    In EtherCAT DC (Distributed Clock) mode, the RxPDO and TxPDO latencies are closely tied to the cycle time and network topology. Here's a breakdown:

    Typical Latency Characteristics - it depends on network position of device, Frame propagation time ≈ (Number of slaves × 1-2 µs) + cable delays, DC sync0 trigger time

    RxPDO Latency (Main Device → Sub Device)

    • Best case: ~25-50% of cycle time
    • Typical: ~50-75% of cycle time
    • Depends on: Slave position in network topology

    TxPDO Latency (Sub Device → Main Device)

    • Best case: ~1 cycle time + propagation delays
    • Typical: ~1-1.5 cycle times
    • Worst case: Up to 2 cycle times
  • 0 in reply to PratheeshGangadhar
    Prodigy 170 points

    We discovered it was a bug in the OTS actuator and verified that the implementation on the AM261 doesn't exhibit this behavior. That said, I'm not following where the 1.7cycles is coming from or why the worst case is up to 2. Can you help explain that?  

  • 0 in reply to Dan
    TI__Guru 51141 points

    Here slave read inputs (t11) on Sync0 and the time it takes for processed inputs to reflect at PLC is at t2 as the read input values are written back via Frame and Main device will pick it up post Sync0 of next cycle