[Etherlab-users] Timeout while setting state INIT.

Fri Mar 6 14:30:12 CET 2026

Hi,

We are still working on the problematic slave which doesn't go to INIT. 
I'm trying to understand the difference by examining wireshark logs.

I noticed these following messages are sent at the beginning. And the 
device changed to INIT itself. It seems as if there is something wrong 
with 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: 0012 (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...0x80

...

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.

You can find the log file at the attachments. I hope someone can give me 
a suggestion.

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/2751da14/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twincat_OfisOP.pcapng
Type: application/octet-stream
Size: 5204556 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20260306/2751da14/attachment-0001.obj>