[Etherlab-users] Timeout while setting state INIT.

Bilko AS, Oguz Dilmac odilmac at bilko-automation.com
Fri Mar 6 14:42:11 CET 2026


Hi,

We are still working on the problematic slave which doesn't go to 
INIT. We received this device and are working with it on my desk. We are 
using ethercat master 1.6.7. There is no other slave in the setup.

I'm trying to understand the difference between twincat and IgH by 
examining wireshark logs. I filtered the register access messages in the 
twincat logs. And noticed these following messages are sent at the 
beginning. And the device changed to INIT itself. Do you think something 
is wrong with the SM configuration?

*...*

*FPRD: 0x80d Return value: 0x30 (SM error / sm enable acknowledged)*

*FPWR: 0x800 16 byte, data: 0    (Clear SM0 and 1?)*
FPWR: 0x800 8 byte, data: 0010000426000100  (Re write SM according to 
XML file?)
FPWR: 0x808 8 byte, data: 0014000422000100
*FPWR: 0x810 16 byte, data: 0     (Clear SM2 and 3?)*

FPWR: 0x620 16 byte, data: 00000009010000000d08000101000000 (define FMMU?)
FPWR: 0x500 1 byte, data: 01

FPWR: 0x120 2 byte, data: 0x0012 (PreOP + Error ACK?)
FPRD: 0x130 Return value: 0x0002 (PREOP)

*FPRD: 0x80D Return value: 0x00 (The error is gone!)*

FPRD: 0x1400 Return value: 0x00 (but WC is zero. I guess the slave 
didn't processed it)

FPRD: 0x130 Return value: 0x0001 (INIT) (Slave went to INIT. But I 
didn't see a write to 0x120 to go to INIT)

FPWR: 0x800 16 byte, data: 0
FPRD: 0x1400 Return value: 0x5208
FPWR: 0x620 16 byte, data: 0
FPRD: 0x1400 Return value: 1024 byte data...

...


Could this be the reason why the slave don't go to INIT when IgH master 
ask?

By the way I tried to write the right values to 0x800 via 
ecrt_reg_request_write. I tried to call this function right after 
ecrt_master_activate. But it didn't work. I also couldn't send both 
erase and write messages. I'm not if I should wait 
between ecrt_reg_request_write calls. Also I'm not sure if I'm calling 
them at the right position.

You can find the twincat log file at the following link. I hope someone 
can give me a suggestion.

https://we.tl/t-kgd1qpUrfG

Best regards,

Oguz.


On 25-Feb-26 3:42 PM, Bilko AS, Oguz Dilmac wrote:
>
> Hi Again,
>
> I just sent some dmesg outputs and a test program using a new ethercat 
> library. Unfortunately it hit a max 200KB attachment limit. Sorry I 
> didn't notice this limit before. And could not cancel my message either.
>
> Anyway, I uploaded the files to wetransfer. I also uploaded a 
> wireshark log of twincat while the problem device goes to OP. Here is 
> the link:
>
> https://we.tl/t-Yl7iRMSadB
>
> I also copy my previous message here:
>
> /Hello,
> / /
> We went to customer side and used a test PC with ethercat library 
> 1.6.7. We also used slave timeout function with 10 seconds.
> / /
> We build a simple setup with only one device and one test PC. Still 
> the old device is going OP, and the new device don't.
> / /
> At the attachments you can find some dmesg outputs. I also attached 
> the simple test program I used.
> / /
> Some explanations for dmesg outputs:
> / /
> * dmesg.OK.txt: Output for the working device. I just put it here as a 
> reference
> / /
> * dmesg.Problem.txt: Output of the problematic device.
> / /
> * dmesg.Problem.freerun.txt: I tried to activate freerun with 
> ecrt_slave_config_dc(sc, 0, 0, 0, 0, 0); I put it right before 
> ecrt_master_activate().
> / /
> * dmesg.Problem.ManualStateChange: I tried to change state via command 
> line tool.
> / /
> We also checked and see that both devices are going to OP with 
> twincat. If you suggest a way to get some log from twincat, we can try.
> / /
> We are stuck 🙁 If you have any idea It would be great.
> / /
> Best regards,
> / /
> Oguz. /
>
>
> On 20-Feb-26 1:30 PM, Richard Hacker wrote:
>> On Fri, 2026-02-20 at 12:49 +0300, Bilko AS, Oguz Dilmac wrote:
>>> Hi,
>>>
>>> We will try to install the newest ethercat library version.
>>>
>>> By the way, we tried one version older of this device. It goes to OP
>>> with no problem.
>> Well, this shows that your configuration is probably not the issue and
>> is at the problem is at the slave's side
>>
>>
>>> Also our customer has a bechoff controller as well, and they say that
>>> with twincat both devices are going to OP without a problem.
>> TwinCAT is not the standard, neither is our EtherCAT master. However,
>> both should implement the standard, but they do it differently
>> (naturally), especially regarding timing. The standard however ensures
>> that EtherCAT masters and slaves are immune to timing issues, but there
>> are always exceptions!
>>
>>> We will try to go to the customer and check with the newest ethercat
>>> master version. We are also considering to connect the both devices
>>> to
>>> the twincat and see if the twincat behaves different. Do you think
>>> checking the transmitted data via wireshark worth trying?
>> You can try, but I do not see that you'll get much insight using
>> wireshark. The master commands the slave to go to INIT and there is
>> simply no reply from the slave acknowledging the state change. That is
>> why the master times out and gives up trying to bring the slave online.
>>
>> Going to INIT is such a primitive state change for a slave that there
>> should be absolutely _no_ reason it takes any amount of time. So I am
>> not even convinced that ecrt_slave_config_state_timeout() would work.
>>
>> I only know that some (complex) slaves may take time between PREOP-
>>> SAFEOP and SAFEOP->OP transition when certain hardware needs to be
>> configured based on its configuration. But your slave is not there yet.
>>
>> Before you use wireshark you can try switching debug to 1
>> `ethercat debug 1`
>>
>>
> -- 
> Oguz Dilmac
>
> Bilko AS, R&D Manager
> ====================================
> Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2536
> TR-34384 Okmeydani Istanbul Turkey
> Tel : +90 212 563 00 00
> e-mail :odilmac at bilko-automation.com
> web site :http://www.bilko-automation.com
> https://www.youtube.com/@LyncaCNC

-- 
Oguz Dilmac

Bilko AS, R&D Manager
====================================
Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2536
TR-34384 Okmeydani Istanbul Turkey
Tel : +90 212 563 00 00
e-mail :odilmac at bilko-automation.com
web site :http://www.bilko-automation.com
https://www.youtube.com/@LyncaCNC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20260306/ea4e0d8e/attachment.htm>


More information about the Etherlab-users mailing list