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

Board Configuration over Ethercat whith encoder

Home Forums SOMANET Software Communication layer software Board Configuration over Ethercat whith encoder

This topic contains 9 replies, has 0 voices, and was last updated by  peterpoon 3 years, 4 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #1530



    Here is the configuration of my test setup:

    • IFM-100 C22 Ethercat, with the app_demo_slave_ethercat_motorcontrol application flashed on it
    • running the application app_demo_master_cyclic_position
    • no motor/sensor yet connected

    when I start the master application with the original code, everithing goes well. As nothing is connected I don’t see the position and velocity updates but I see that it is running and closed after 3sec.

    But when I change the bldc_motor_config_1.h file and change the ” #define SENSOR_SELECTION_CODE_1    QEI_WITH_NO_INDEX”, after compilation and restart the program blocks before or after the update of the motor control parameters through ethercat. Do you know what could be the problem ?



    I tried to change the user_config.h file from the slave side bu updating the MOTOR_FEEDABCK variable to QEI_SENSOR, but in this case the code doesn’t compile due to ” Error: Constraints check FAILED for tile[3].” (I tested the develop branch and this error happens also)




    are you compiling for release or debug? Try changing the optimisation to O2 in the Makefile, it should solve the Constrains check error. And in general for the 2.0 release of the software please use develop branch of SOMANET-OS, it contains fixes to some known issues.

    QEI_WITH_NO_INDEX and QEI_WITH_INDEX provide equal functionality. Does QEI_WITH_INDEX also create a block during the parameters update?

    For the develop branch of SOMANET-OS please update the SII configuration of the SOMANET-OS. The mailbox size has been changed that also may cause the parameters update block:

    ethercat sii_write -p 0 Somanet_ECAT-v3r0.sii





    Did this work for you? I changed to develop branch and updated the SII configuration. But the code still hangs for me. and I get SDO update error. I am also getting a new error now when I check dmesg: Ethercat ERROR 0-0: Reception of CoE upload request for SDO 0x6091:0 failed with timeout after 1001 ms: No response.”

    And when the master prints ‘updating motor parameters for all connected nodes’, the slave receives ET_ECALL, Application exception and exits the code.

    How do I go back to the previous version of ssi file?

    Did it work for anyone?



    I have still the same problem. It begins to be for me urgent to solve it.

    The documentation on the website seems not fully up-to-date compared to the last version of the sotware. In order to be sure to done everything correctly, would it be possible to describe the full process from the download of the libraries in XtimeComposer to the flashing and execution of the master code (including any required flashing of the board) ?

    After updating the Ethercat firmware, when checking slaves on the EtherCAT bus, the name of the board is now “CiA402 Drive”. Is it what you would expect ?

    Is there another test we could conduct ?

    Thank you,





    In the meantime, I found a more general problem that could explain our issues. I followed the tutorial to checkout the develop branch from the SOMANET-OS git repository. I found that although I am well in the ” develop” branch for the main files of SOMANET-OS, I was not in the develop branch for the submodules. Even after forcing the develop branch inside the submodules (e.g. ethercat) and on the SOMANET-OS, if I make a “git submodule update --init“, all the submodules come back to the master branch (at least the list of file in my folder is changing and similar again to the master branch).

    Either I have an issue to understand how to use git (that is possible) or, is there a chance that a configuration in the git repository is not well done.

    After getting the develop branch, in xTimeComposer I have an issue to build the app_demo_slave_ethercat_motorcontrol with a lot of modules that are not in my folder (e.g. module_foc).

    What can I do ?






    Hi Peirre,

    sorry for the troubles you have to go through! It is a period of vacations and we just do not have enough resources to take care of all the issues while working on the new software release.

    The actual development brunch of our components will not work for sure, it is a work in progress. The SOMANET-OS development brunch points just to certain commits and not to the actual development brunches of repositories. You can see the commits numbers on github. Alternatively you can use the git reset –hard <commit_number> command to do the same what submodules do. But have you checked out SOMANET-OS repo with –recursive at the first place? If not, submodules will not work.

    I hope that helps,




    Hello Peirre,

    It worked for me now though I still get EtherCAT warning messages. This is what I did:

    I changed the git branch from the terminal. Then I made a new workspace in xTIMEcomposer and imported separately just the slave and master examples along with SOMANET-OS modules and motor config folders into the new workspace. I compiled the master directly from terminal and the slave from the xTIMEcomposer and ran it on the board and the ethercat communication part seems to be working now.

    But I get these warnings: 2 datagrams UNMATCHED!

    Datagram f258908c (domain0-0-main) was skipped 2 times.

    Hope it helps!




    I started from scratch also, but still experiencing a problem when I switch from Hall (working) sensor to QEI (hanging after the update of the parameters).

    I ran the code from xTimeComposer and I received the following exception:

    Program received signal ET_LOAD_STORE, Memory access exception.
          [Switching to tile[1] core[0]]
          ethercat_drive_service (profiler_config=@0x1fdd8, pdo_out=2147616770, pdo_in=2147616514, coe_out=2147616258, i_commutation=130608, i_hall=130624, i_biss=130592, i_torque_control=130584, i_velocity_control=130568, i_position_control=130576) at /home/haco/X
          546                                i_qei.set_qei_config(qei_params);

    Maybe this can help you to understand my problem.

    Here are the steps I followed to run the program:

    1. git clone --recursive
    2. git pull
    3. git submodule update
    4. git checkout develop
    5. git submodule update --init
    6. Import in xTimeComposer of the examples, libraries and modules (by copy them in a specific workspace, all of them on the same folder level)
    7. In XTimecomposer, I still need to change some path in the Makefile (I need to remove ” example” for the motor config)
    8. Update the files for the board configurations
    9. Update of the Ethercat path (due to my personal installation, but that is working)
    10. Compile the master and slave application
    11. Flash the slave application on the board and re-power it on
    12. Run the slave application from xTimeComposer
    13. Run the master application in the terminal

    There, if I have selected hall sensors in the motor config, it works. If I have selected the QEI, it hangs (see excpetion above)




    I finally succeeded to make the code working with the encoder interface. Here are all the required changes I had to make to the code, please comment on them for their relevance:

    • On the slave side, I need to initially configure the slave board with the QEI_SENSOR parameter (in the user_config.h file of the slave motor configuration). If I let there HALL_SENSOR, the example with EtherCAT hangs.
    • Form this change I needed to update the slave code (demo slave_ethercat_motorcontrol) to succeed the compilation as proposed by Romuald (
    • On the master side, in the motor configuration, I have to select QEI_SENSOR (although QEI_WITH_INDEX or QEI_NO_INDEX is proposed in the brackets)

    All the code compiles and I am able to start the master cyclic position code with Ethercat communication, and read the sensor value.



    Hello Pierre and thank you very much for your patience and contribution!

    • The sensor is needed to be defined before you compile the source, that is correct. The reason is the overlapping ports used by the BiSS interface otherwise. That’s why there are those ugly #if #else compiler flags in the main file. It is fixed in the new software that we are preparing for release.
    • I believed this fix was included in the develop branch of SOMANET-OS, sorry for that.
    • Probably this thing we also overlooked. I will check if I can patch that state.
Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.