• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 32 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: EtherCAT PDO Configuration

Sapna N
Prodigy 10 points

Part Number: AM6442

Hello,

I am trying to add new PDOs to the existing ethercat subdevice beckhoff ssc demo. I added the required data to the tiescappl.xlsx and created slave source files through the SSC tool.

I then flashed the generated xml file to the EEPROM through the EEPROM programmer. I set up a TwinCAT project using instructions from this link:
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/2026_00_00_06/docs/api_guide_am64x/ETHERCAT_SUBDEVICE_DEMO_TWINCAT.html


None of the changes I made were reflected. The TwinCAT threw an error:

"State change aborted (requested SAFEOP, back to PREOP)
"PREOP to SAFEOP failed. Error 'check device state for SAFEOP. AL Status '0x0012' read and '0x004' expected. AL Status Code '0x001e - Invalid SM IN Cfg'

I then put the generated TIESC.xml file in the TwinCAT/3.1/Config/Io/EtherCAT folder. Only then the TwinCAT showed the updated PDO list and the application ran successfully. 

I have the following questions:
1. The TwinCAT is supposed to read the EEPROM of the device to get the slave details. Why did it not happen? I created another project, restarted the TwinCAT application but still it did not fetch the details.
The new details were fetched without having any reference to the xml file in the TwinCAT folder only if device info was changed. What is the correct behaviour?
2. Is editing the tiescappl.xlsx and generating slave stack source files from the SSC tool the only way to perform this operation? What is the alternate method to add/modify the PDOs without involvement of the SSC tool?

Kindly guide me through the process.

SN 

  • 0
    TI__Genius 14025 points

    Hi Sapna,

    Sapna N said:
    1. The TwinCAT is supposed to read the EEPROM of the device to get the slave details. Why did it not happen? I created another project, restarted the TwinCAT application but still it did not fetch the details.

    TwinCAT does not treat the live SDevice EEPROM as the primary source for PDO/SM configuration during engineering. The flow is:

    1. When TwinCAT scans a SDevice, it reads only the identification information from the SII (EEPROM) — Vendor ID, Product Code, and Revision Number (plus serial number).
    2. It then looks up its local ESI cache (TwinCAT/3.1/Config/Io/EtherCAT) for an XML entry whose Vendor ID/Product Code/Revision Number matches.
    3. If a match is found, TwinCAT trusts that cached ESI file for the PDO list, Sync Manager assignment, CoE object dictionary structure, etc. It does not re-derive the PDOs from the SM PDO-assignment area of the live EEPROM each time, even though that data is technically present in the EEPROM.
    4. Only if no matching ESI is found (e.g., because you changed the Revision Number, so the previously cached description no longer matches) does TwinCAT fall back to building a "generic"/scanned configuration directly from what it can read from the EEPROM at that moment.
    This is exactly why:
    • Simply flashing the new TIESC.xml-derived EEPROM contents did nothing as the old cached ESI (from your first install) still matched on Vendor/Product/Revision, so TwinCAT kept using the stale cached PDO definitions.
    • New device creation/restarting TwinCAT didn't help either, because the stale ESI was still sitting in the ESI folder and still matched.
    • It only worked when you dropped the new TIESC.xml into the ESI folder. That's the correct, supported way to make TwinCAT recognize new PDOs.
    • In your case, 0x001e - Invalid SM IN CFG error was thrown by TwinCAT as the PDO lengths had a mismatch with respect to the configuration in the application (SMLength != nPdInputSize, where SMLength is the length read from the ESI and nPdInputSize is the value configured in the SDevice application).
    Correct behavior / best practice:
    • Anytime you regenerate the ESI (TIESC.xml) with new/changed PDOs, always copy it into TwinCAT/3.1/Config/Io/EtherCAT (replacing/adding alongside the old one).
    • Make sure you re-launch the TwinCAT GUI so that the device description table to TwinCAT is refreshed and it's able to read the newly added ESI file.
    Sapna N said:
    2. Is editing the tiescappl.xlsx and generating slave stack source files from the SSC tool the only way to perform this operation? What is the alternate method to add/modify the PDOs without involvement of the SSC tool?

    For pure re-mapping of existing CoE objects, you can skip the SSC tool and just edit SDOs/ESI directly. For adding brand-new PDOs/data items, tiescappl.xlsx + SSC tool regeneration of the SDevice stack source is the required and only supported path (in my knowledge), since it keeps firmware and ESI in sync.

    Regards,
    Aaron