Integrated Motion
Items : 0
Subtotal : 0,00 
View CartCheck Out

Enable PDO Configuration: no or yes?

Home Forums SOMANET Software Communication layer software Enable PDO Configuration: no or yes?

This topic contains 6 replies, has 0 voices, and was last updated by  sirop 3 years, 2 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #1571



    I am just trying out your example .

    I could configure a set of PDOs with this script:

    echo ‘rescan’
    ethercat rescan
    sleep 1
    echo ‘clear and set RxPdo’
    ethercat $POS –type uint8 download 0x1C12 0 0
    ethercat $POS –type uint8 download 0x1600 0 0
    ethercat $POS –type uint32 download 0x1600 1 0x60400010
    ethercat $POS –type uint32 download 0x1600 2 0x60ff0020
    ethercat $POS –type uint8 download 0x1600 0 2
    ethercat $POS –type uint16 download 0x1C12 1 0x1600
    ethercat $POS –type uint8 download 0x1C12 0 1


    echo ‘clear and set TxPdo’
    ethercat $POS –type uint8 download 0x1C13 0 0
    ethercat $POS –type uint8 download 0x1A00 0 0
    ethercat $POS –type uint32 download 0x1A00 1 0x60410010
    ethercat $POS –type uint32 download 0x1A00 2 0x606c0020 # act velocity
    ethercat $POS –type uint8 download 0x1A00 0 2 # number of var in this PDO
    ethercat $POS –type uint16 download 0x1C13 1 0x1A00 # list TxPdo
    ethercat $POS –type uint8 download 0x1C13 0 1 # number of TxPdo
    ethercat rescan
    sleep 1
    ethercat pdos

    But  ethercat slaves -v yields:

    CoE details:
    Enable SDO: yes
    Enable SDO Info: yes
    Enable PDO Assign: no
    Enable PDO Configuration: no
    Enable Upload at startup: no
    Enable SDO complete access: no

    So how could I configure PDOs if  Enable PDO Configuration: no is set?





    Frank Jeschke

    Hello Sirop,

    the CoE flag “Enable PDO Configuration” and “Enable PDO Assign” are intentionally set to no because our current EtherCAT slave firmware does not support dynamic change of the PDO setup.

    Thanks for pointing out that the objects 0x1A00, 0x1600 and 0x1Cxx are changeable via SDO downloads.

    If you really want to change the PDOs you have to change the ESI file (a configurator will be available soon) and you have to change the firmware itself to support the new PDOs.

    But the question is, do you really need to change the PDOs? Since we took some effort in the definition of the PDOs for use as CiA402 drive the most use cases should be covered by the current solution. In the next revision of the EtherCAT slave firmware we also support 4 extra PDO in the RX and TX line for user specific content.






    Thanks for your answer.

    I could live for a while with preset PDOs as I am not afraid to change the firmware thus effectively changing the PDO mapping.

    I uploaded a gist of the current EEPROM to .

    As you see, it says:

    Supported Mailboxes:
    CoE ………………….. True
    EoE ………………….. False
    FoE ………………….. True
    SoE ………………….. False
    VoE ………………….. False

    I guess it is the reason why I could use ethercat download …  .


    BTW, does your forum really support thread subscription? As it is the second time I do not get thread updates/replies per email.





    Frank Jeschke

    Hello Sirop, the SDO upload of the PDO definition objects shouldn’t be possible. Sadly in your current firmware version the writeable flag is wrongly set to true in the objects access permissions. So the upload works, but actually the new PDO configuration is not setup in the slave firmware (which is not possible because of various reasons). So, the pure support of CoE does not support the conclusion. 😉

    As for the forum, I informed our IT infrastructure stuff, it should work and they have to examine why it doesn’t. Thank you for pointing out.






    Well, I could restrict the PDOs (entries) to a subset of the preconfigured PDOs with the above quoted shell script,

    but anyway I wanted to ask a different question now.


    I managed to change dictionary.h as well  Somanet_CiA402-single.xml  thus adding one RxPDO entry and one TxPDO entry.

    That worked fine with

    where I only changed these lines:

    if (count>0) {
    pdo_out <: 9;
    for (i=0; i< 9; i ) {
    //pdo_out <: inBuffer[i];
    pdo_out <: 0xCCDD;



    However as soon as I added  the seventh  TxPDO entry both to dictionary.h and to Somanet_CiA402-single.xml ,

    the slave app did no longer send out TxPDO values. Receiving RxPDO values still worked.

    Lines changed in main.xc:

    if (count>0) {
    pdo_out <: 11; // change from 9 to 11 as the 7th TxPDO entry is 32 bit long
    for (i=0; i< 11; i ) {
    //pdo_out <: inBuffer[i];
    pdo_out <: 0xCCDD;




    You might argue that the problem occurs due to some misconfiguration on my side,

    but before I try to narrow the problem, could you please confirm to me that  slave module can receive and send

    if the number of RxPDO entries is not equal to the number of TxRPDO entries?






    Just moved the debug output from static void pdo_handler(chanend pdo_out, chanend pdo_in) of main.xc

    to  void ethercat_service(…) ,  and the values of TxPDO entries get sent out now.

    I could think that debugging with print functions would introduce some delay,

    but could not imagine it would be so crucial.



    Happy to hear that it worked!

    Prints introduce significant delays, but consider redirecting them via XSCOPE:

    Still that will have delays, but faster then via DEBUG interface.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.