• State Resolved
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 513 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

IND-COMMS-SDK: Writing to Vendor Info space in EtherCAT EEPROM.

AM2432: AM243x PRUICSSG EtherCAT Core: stop working counters

Martin Schwendinger
Prodigy 85 points

Part Number: AM2432

Hello,

first I want to thank you for your support for AM2432: IND-COMMS-SDK: Triple-Buffer of EtherCAT Sub-Device on ICSSG1 seems broken - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums. Issue seems gone now. However, the thread is locked so I cannot mark it as solved or reply.

Also https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1554347/ind-comms-sdk-writing-to-vendor-info-space-in-ethercat-eeprom is locked, but I never got an update on this one. Would still be interested.

Now the new topic concerning EtherCAT Core on ICSSG1:
Is there a way to disable the incrementation of the working counters for LRW datagram, which reads and writes the PDO data. So that in case of an error the EtherCAT sub-device can stop incrementing the working counters to signal that PDO data is invalid.

I tried to use "void DisableSyncManChannel(UINT8 channel)" for channel 2 and 3 (PDO data), which writes to "PDI Activate SyncManager" register, however this does not prevent the working counter of the LRW datagram from being increased. 

I also tried to write manually to the registers of sync manager 2 (0x0810) and 3 (0x0818). However, even clearing the entire config of the sync managers (all 8 bytes) seems not to have the effect of preventing the working coutner from beeing increased. So is there a way to achieve this?

Also I would be happy to receive feedback, if this is a valid option regarding the EtherCAT Spec. Usually I assume that OP->(SAFEOP+ERROR) is enough to communicate an error to the master, which may also mean that input and output PDO data is not valid anymore. However, some colleagues push to also stop incrementing the working counters.

Thank you for your support.

Kind regards,
Martin

  • 0
    TI__Genius 12595 points

    Hi Martin,

    Thank you for posting your query. I will have a look into your requirements and get back with details by Monday. 

    Martin Schwendinger said:
    Also I would be happy to receive feedback, if this is a valid option regarding the EtherCAT Spec. Usually I assume that OP->(SAFEOP+ERROR) is enough to communicate an error to the master, which may also mean that input and output PDO data is not valid anymore. However, some colleagues push to also stop incrementing the working counters.

    I believe the ETG describes that SubDevices shall transition to SAFEOP+ERROR when the application detects an error condition. This transition clearly signals to the master that process data may no longer be valid.

    The Working Counter (WKC), indicates successful datagram processing at the communication layer - specifically whether the frame was correctly received and the read/write operation completed. A missing WKC increment could indicate:

    • Physical cable issues
    • Slave hardware failure
    • Frame processing errors
    • Your intentional suppression

    The master cannot distinguish between these scenarios. So I'm not really sure if manipulating the WKC for signaling invalid PDO data.

    Regards,
    Aaron

  • +1 in reply to Aaron Thomas
    TI__Genius 12595 points

    Hi Martin,

    So we had a quick look at your requirement and the way to not make the WKC increment is by modifying the access permission (read to write or write to read) of the FMMU/SM Configuration registers, which will invalidate the PDO entry.

    Since the FMMU/SM configuration registers have Write access only from the MainDevice side (ECAT R/W, PDI RO), you cannot modify them from the SubDevice side.

    Martin Schwendinger said:
    I tried to use "void DisableSyncManChannel(UINT8 channel)" for channel 2 and 3 (PDO data), which writes to "PDI Activate SyncManager" register, however this does not prevent the working counter of the LRW datagram from being increased. 

    Disabling won't stop the WKC from being incremented.

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 85 points

    Hi Aaron,

    thank you very much for your response. So do I get it correctly that an EtherCAT sub device is simply not expected to disable its own working counter for datagrams except there is really a failure at the communication layer, i.e. inside the EtherCAT sub-device core in ICSSG1? Or is there an other way to disable the WKC?

    Kind regards,
    Martin

  • +1 in reply to Martin Schwendinger
    TI__Genius 12595 points

    Hi Martin,

    Martin Schwendinger said:
    So do I get it correctly that an EtherCAT sub device is simply not expected to disable its own working counter for datagrams except there is really a failure at the communication layer, i.e. inside the EtherCAT sub-device core in ICSSG1?

    Correct.

    Martin Schwendinger said:
    Or is there an other way to disable the WKC?

    There is no other way to disable the WKC for PDO transmissions within the SubDevice.

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 85 points

    Hi Aaron,

    just for you to know: we are currently in a discussion with the ETG about the correct behaviour of the working counters and if and when the slave should (be able to) turn them off.

    The discussion is still ongoing.

    (I also want to delay the locking of this thread with this post.)

    Kind regards,
    Martin

  • 0 in reply to Martin Schwendinger
    TI__Genius 12595 points

    Hi Martin,

    Thank you for the heads-up. 

    Threads automatically Lock after 30 days of no replies (regardless of resolution status). So, either of us should ping here to keep it open. I think this is fine for now.

    Even if it gets locked, click the yellow "Ask a related question" button on the top right of your screen. 

    This will open a form to create a new (related) thread.  When the related question thread is published, it will automatically display the link to the original thread where you started from.

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 145 points

    Hello,
    if the MainDevice acess the ESC DPRAM which is controlled by a SyncManager, the SM channel is enabled (0x806+SMno*8.0, set via the MainDevice) and the SM is deactivated (0x807+SMno*8.0) the WKC shall not be incremented.

    So it seems that the current ESC behavior is not correct.

    See also:
    - EtherCAT compendium : www.ethercat.org/.../EtherCAT_Compendium.pdf, clause 3.11
    - EtherCAT technology description: www.beckhoff.com/.../127360849, clause 8.7

  • 0 in reply to Rainer Hoffmann
    TI__Genius 12595 points

    Hi Rainer,

    Thank you for the clarification. I've created an internal ticket to fix the WKC behavior for deactivated SM.

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 145 points

    Hi Aaron,

    thanks for the feedback. Please forward my contact details if further clarification/discussion is needed.

    Regards,

    Rainer

  • 0 in reply to Rainer Hoffmann
    TI__Genius 12595 points

    Sure Rainer. Thank you!

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    TI__Genius 12595 points

    Pinging here to keep the thread open.

    Regards,
    Aaron