[Etherlab-users] Timeout while setting state INIT.
Bilko AS, Oguz Dilmac
odilmac at bilko-automation.com
Wed Mar 25 10:56:18 CET 2026
Hi Richard,
First of all I'd like to thank you for your patience with me.
I agree that I will most likely see the working slave respects to INIT
command. In fact, I already demonstrated to our customer that it works
fine with our controller.
But unfortunately, I can't persuade our customer that the one I have in
my desk is broken. Because I just connected it via twincat, it goes to
OP mode and I can see the process data :(
Yesterday I asked the manufacturer about the model of the ESC used in
this device. Not received a reply yet. Maybe it can tell us something?
Also I'll try the commands you sent, while the master uses the SII
binary file instead of reading directly from the device.
Best regards,
Oğuz.
On 25-Mar-26 10:25 AM, Richard Hacker wrote:
> Hello Oguz,
>
> As far as I can see, your slave is broken! You are not even at the
> application level.
>
> The "ethercat" commands I sent you show that the slave will not go to
> INIT even on an idle bus. Try those commands again with your working
> slave and you will see that it respects the INIT command.
>
>
>
> On Tue, 2026-03-24 at 12:31 +0300, Bilko AS, Oguz Dilmac wrote:
>>
>> Hi Richard,
>>
>> Here are the outputs of the commands after a fresh start. No
>> application is running.
>>
>> lynca at lynca:~$ sudo /usr/local/etc/init.d/ethercat restart
>> Shutting down EtherCAT master 1.6.8 done
>> Starting EtherCAT master 1.6.8 done
>> lynca at lynca:~$ ethercat slave -v
>> === Master 0, Slave 0 ===
>> Device: Main
>> State: PREOP
>> Flag: +
>> Identity:
>> Vendor Id: 0x6167656d
>> Product code: 0x00000000
>> Revision number: 0x00000000
>> Serial number: 0x00000000
>> DL information:
>> FMMU bit operation: no
>> Distributed clocks: yes, 64 bit
>> DC system time transmission delay: 0 ns
>> Port Type Link Loop Signal NextSlave RxTime [ns] Diff [ns]
>> NextDc [ns]
>> 0 MII up open yes - 811350812
>> 0 0
>> 1 MII down closed no - - -
>> -
>> 2 N/A down closed no - - -
>> -
>> 3 N/A down closed no - - -
>> -
>> Mailboxes:
>> Bootstrap RX: 0x1000/1024, TX: 0x1400/1024
>> Standard RX: 0x1000/1024, TX: 0x1400/1024
>> Supported protocols: CoE, FoE
>> General:
>> Group: SSC_Device
>> Image name:
>> Order number: Megatec_ESC_NLCH
>> Device name: Megatec_ESC_NLCH
>> 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: yes
>> Flags:
>> Enable SafeOp: no
>> Enable notLRW: no
>> Current consumption: 0 mA
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0000
>> 0x98 152
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0001
>> 0x01 1
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0002
>> 0x0001 1
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0004
>> 0x08 8
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0005
>> 0x08 8
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0006
>> 0x08 8
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0007
>> 0x0f 15
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0008
>> 0x01cc 460
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
>> 0x0002 2
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
>> 0x0002 2
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
>> 0x0000 0
>> lynca at lynca:~$ sudo ethercat state -p0 init
>> lynca at lynca:~$ ethercat slaves
>> 0 0:0 PREOP E Megatec_ESC_NLCH
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
>> 0x0001 1
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
>> 0x0002 2
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
>> 0x0000 0
>> lynca at lynca:~$ sudo ethercat state -p0 preop
>> lynca at lynca:~$ ethercat slaves
>> 0 0:0 PREOP + Megatec_ESC_NLCH
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
>> 0x0001 1
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
>> 0x0002 2
>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
>> 0x0000 0
>> lynca at lynca:~$
>>
>>
>>
>> The documents of the slave is mostly focused on the application. I
>> screen copied the Ethercat related section below. The rest describes
>> the content of the PDOs
>>
>> ----
>>
>> 1 Introduction
>> This document describes a communication protocol between the CNC and
>> the processing optic using the EtherCAT bus.
>> All information is transferred inside cyclical process data objects
>> (PDO). Specific data in PDOs is referenced as following: TxPDO 4 –
>> TxPDO, word 4 TxPDO 2/3 – TxPDO, word 2, bit 3 Words and bits are
>> counted from 0.
>> After the power is switched on the processing optic’s controller is
>> booted up and references the lens motor. This takes approx. 10
>> seconds. Afterwards that the optic is ready for operation and does
>> not need any additional initialization.
>> 2 EtherCAT protocol description
>> The processing optic is an EtherCAT slave device. The minimum cycle
>> time is 1 millisecond.
>>
>>
>> -------
>>
>> Below that point, the document describes the PDO content...
>>
>> By the way, I will ask which ESC controller is used. What else do you
>> suggest to ask?
>>
>> Best regards,
>>
>> Oguz.
>>
>> On 24-Mar-26 11:23 AM, Richard Hacker wrote:
>>
>>
>>>
>>> OK, the slave does not transition to INIT, regardless (0x130 should
>>> match 0x120).
>>>
>>> Next test:
>>> with a fresh restart (no application running)
>>> ethercat slave -v
>>> ethercat reg_read -p0 -tuint8 0x0000
>>> ethercat reg_read -p0 -tuint8 0x0001
>>> ethercat reg_read -p0 -tuint16 0x0002
>>> ethercat reg_read -p0 -tuint8 0x0004
>>> ethercat reg_read -p0 -tuint8 0x0005
>>> ethercat reg_read -p0 -tuint8 0x0006
>>> ethercat reg_read -p0 -tuint8 0x0007
>>> ethercat reg_read -p0 -tuint16 0x0008
>>> ethercat reg_read -p0 -tuint16 0x0120
>>> ethercat reg_read -p0 -tuint16 0x0130
>>> ethercat reg_read -p0 -tuint16 0x0134
>>> ethercat state -p0 init
>>> ethercat sl
>>> ethercat reg_read -p0 -tuint16 0x0120
>>> ethercat reg_read -p0 -tuint16 0x0130
>>> ethercat reg_read -p0 -tuint16 0x0134
>>> ethercat state -p0 preop
>>> ethercat sl
>>> ethercat reg_read -p0 -tuint16 0x0120
>>> ethercat reg_read -p0 -tuint16 0x0130
>>> ethercat reg_read -p0 -tuint16 0x0134
>>>
>>> The important address is 0x0134 (AL Status code). Can you check in
>>> the
>>> documentation what the manufacturor writes about the status code
>>>
>>>
>>> On Tue, 2026-03-24 at 10:36 +0300, Bilko AS, Oguz Dilmac wrote:
>>>
>>>>
>>>> Hi Richard, Graeme,
>>>>
>>>> I was out of the office. Thank you for the suggestions. Graeme
>>>> I'll
>>>> try
>>>> to look into it.
>>>>
>>>> Mr Richard, here are the outputs of the commands after I powered
>>>> both
>>>> PC
>>>> and the slave:
>>>>
>>>> lynca at lynca:~$ sudo /usr/local/etc/init.d/ethercat restart
>>>> Shutting down EtherCAT master 1.6.8 done
>>>> Starting EtherCAT master 1.6.8 done
>>>> lynca at lynca:~$ ethercat slave
>>>> 0 0:0 PREOP + Megatec_ESC_NLCH
>>>> lynca at lynca:~$ ethercat slaves
>>>> 0 0:0 PREOP + Megatec_ESC_NLCH
>>>> lynca at lynca:~$ sudo ethercat state -p0 init
>>>> lynca at lynca:~$ ethercat slave
>>>> 0 0:0 PREOP E Megatec_ESC_NLCH
>>>> lynca at lynca:~$ sudo ethercat state -p0 preop
>>>> lynca at lynca:~$ ethercat slave
>>>> 0 0:0 PREOP + Megatec_ESC_NLCH
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint32 0x900
>>>> 0x0af50b04 183831300
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint64 0x910
>>>> 0x00000051a7927504 350703744260
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x120
>>>> 0x0001 1
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x130
>>>> 0x0002 2
>>>> lynca at lynca:~$
>>>>
>>>> And these are executed while the application is running:
>>>>
>>>> lynca at lynca:~$ sudo ethercat slave
>>>> 0 0:0 PREOP E Megatec_ESC_NLCH
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x120
>>>> 0x0001 1
>>>> lynca at lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x130
>>>> 0x0002 2
>>>>
>>>> The installed ethercat master is 1.6.8 with Mr James Benway's
>>>> patch
>>>> for
>>>> reading sii from a
>>>> file (
>>>> https://github.com/DSI-Gleeble/ethercat/tree/sii-from-file).
>>>> But I
>>>> removed the binary sii files so that the master can read from
>>>> slave
>>>> as
>>>> normal.
>>>>
>>>> Can you see something?
>>>>
>>>> Best regards,
>>>>
>>>> Oguz.
>>>>
>>>>
>>>> On 20-Mar-26 6:34 PM, Richard Hacker wrote:
>>>>
>>>>>
>>>>> My suspicion is that your problem is way before the master
>>>>> tries to
>>>>> configure the slave, as I have said before.
>>>>>
>>>>> When the master is activated, it jogs the slave through the
>>>>> INIT,
>>>>> PREOP, SAFEOP and eventually OP states. A slave gets configured
>>>>> (SDO
>>>>> parameters, PDO setup) between the PREOP and SAFEOP state --
>>>>> but
>>>>> your
>>>>> slave never gets there. Your slave might go into INIT, but
>>>>> somehow
>>>>> the
>>>>> master does not get this state change.
>>>>>
>>>>> Can you change the slave state from the command line? With your
>>>>> slave
>>>>> attached but without your application running (i.e. idle free-
>>>>> run
>>>>> bus),
>>>>> what is the output of:
>>>>> ethercat slave
>>>>> ethercat state -p0 init
>>>>> ethercat slave
>>>>> ethercat state -p0 preop
>>>>> ethercat slave
>>>>> ethercat reg_read -p0 -tuint32 0x900
>>>>> ethercat reg_read -p0 -tuint64 0x910
>>>>> ethercat reg_read -p0 -tuint16 0x120
>>>>> ethercat reg_read -p0 -tuint16 0x130
>>>>>
>>>>> Now start your application and:
>>>>> ethercat state
>>>>> ethercat reg_read -p0 -tuint16 0x120
>>>>> ethercat reg_read -p0 -tuint16 0x130
>>>>>
>>>>>
>>>>> -p0 assumes the affedted slave is the first slave in the
>>>>> network.
>>>>> Adjust accordingly if that is not the case.
>>>>>
>>>>> On Fri, 2026-03-20 at 00:02 +0000, Graeme Foot wrote:
>>>>>
>>>>>>
>>>>>> Hi Oguz,
>>>>>>
>>>>>> If this is a potential fix for your slave, you would require
>>>>>> more
>>>>>> separation, plus I’m not sure you got your reads vs writes
>>>>>> assigned
>>>>>> quite right. i.e. from your log 0x6000:01 is being assigned
>>>>>> to
>>>>>> domain 0 when it looks like it should be assigned to domain
>>>>>> 1.
>>>>>>
>>>>>>
>>>>>> The issue with the Texas Instruments ESC’s in particular is
>>>>>> that
>>>>>> if
>>>>>> you use one domain the writes (control) and reads (status)
>>>>>> are
>>>>>> too
>>>>>> close together for the ESC’s syncs to handle gracefully.
>>>>>> E.g.:
>>>>>>
>>>>>> + domain 0 -------------------+
>>>>>>
>>>>>>>
>>>>>>> [slave 0 write][slave 0 read]|
>>>>>>>
>>>>>>
>>>>>>
>>>>>> If you split them into two domains you get:
>>>>>>
>>>>>> + domain 0 -----+ domain 1 ----+
>>>>>>
>>>>>>>
>>>>>>> [slave 0 write]|[slave 0 read]|
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Which timing wise is no real difference and still a problem.
>>>>>>
>>>>>> But if you add a few more slaves (they don’t even need to be
>>>>>> online)
>>>>>> you get:
>>>>>>
>>>>>> + domain 0 -------------------------+ domain 1 --------------
>>>>>> ----
>>>>>> ----
>>>>>> --+
>>>>>>
>>>>>>>
>>>>>>> [slave 0 write][slave 1 write][...]| [slave 0 read][slave 1
>>>>>>>
>>>>>>
>>>>>> read][...]|
>>>>>>
>>>>>> You can see you now have more separation between the slave 0
>>>>>> write
>>>>>> and read.
>>>>>>
>>>>>> In your example (apart from the potential incorrect
>>>>>> allocation
>>>>>> which
>>>>>> could itself cause issues) I don’t think the EL2008 would be
>>>>>> enough
>>>>>> to give a big enough separation (only 1 byte?). Try adding
>>>>>> two
>>>>>> or
>>>>>> three more of your problem slaves (they’re around 78 bytes
>>>>>> each).
>>>>>>
>>>>>>
>>>>>> Here’s some background info on the Texas Instruments
>>>>>> issue:
>>>>>> https://www.ti.com/lit/an/spracj7/spracj7.pdf?ts=1669243747147
>>>>>> * section 3.1.3 describes the TI ESC not working with non-
>>>>>> overlapping PDOs
>>>>>> * Section 3.6 describes a malformed packet issue and its
>>>>>> workarounds, due to overlapping PDOs
>>>>>>
>>>>>> In our cases where we’ve had problems with slaves our
>>>>>> symptoms
>>>>>> were:
>>>>>> 1. On assigning the FMMU configuration the slave would
>>>>>> stop
>>>>>> forwarding on frames
>>>>>> 2. I think we had one that got stuck in INIT, but can’t
>>>>>> remember
>>>>>> for sure
>>>>>>
>>>>>> Regards,
>>>>>> Graeme.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Bilko AS, Oguz Dilmac <odilmac at bilko-automation.com>
>>>>>> Sent: Thursday, 19 March 2026 23:49
>>>>>> To: Graeme Foot <Graeme.Foot at touchcut.com>;
>>>>>> etherlab-users at etherlab.org
>>>>>> Subject: Re: [Etherlab-users] Timeout while setting state
>>>>>> INIT.
>>>>>>
>>>>>> Hi Graeme,
>>>>>> I connected a EK1100 bus coupler and a EL2008 digital output
>>>>>> card.
>>>>>> The first slave is the EK1100, and my device stay at the end.
>>>>>> I created two domains
>>>>>> Unfortunately the device still don't go to INIT.
>>>>>> Here, I put my test code and the dmesg output:
>>>>>> https://we.tl/t-Dj1MtId6LA
>>>>>> Best regards,
>>>>>> Oguz.
>>>>>>
>>>>>>
>>>>>> On 19-Mar-26 1:16 AM, Graeme Foot wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Oguz,
>>>>>>>
>>>>>>> It’s not looking likely to be an SII problem then.
>>>>>>>
>>>>>>> From the log it looks like you’re using a single
>>>>>>> Read/Write
>>>>>>> domain. I don’t recall if you mentioned, have tried
>>>>>>> putting it
>>>>>>> in
>>>>>>> separate read and write domains? If you try this, also
>>>>>>> ensure
>>>>>>> that
>>>>>>> there are at least two other separate read and write domain
>>>>>>> slaves
>>>>>>> also configured in your system.
>>>>>>>
>>>>>>> I’ve had a few slaves in the past (generally with Texas
>>>>>>> Instruments
>>>>>>> ESC’s) that work well with overlapped PDO’s in a single
>>>>>>> Read/Write
>>>>>>> domain (TwinCat’s default method), but fail when the PDO’s
>>>>>>> are
>>>>>>> not
>>>>>>> overlapped (EtherLab’s default). If this is the case you
>>>>>>> can
>>>>>>> put
>>>>>>> them in separate read and write domains to separate them
>>>>>>> within
>>>>>>> the
>>>>>>> EtherCat frame. But, you need to ensure there’s a couple
>>>>>>> of
>>>>>>> other
>>>>>>> read and write domain devices also configured to ensure
>>>>>>> there’s
>>>>>>> enough separation in the frame.
>>>>>>>
>>>>>>>
>>>>>>> Graeme.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Bilko AS, Oguz Dilmac<odilmac at bilko-automation.com>
>>>>>>> Sent: Thursday, 19 March 2026 02:33
>>>>>>> To: Graeme Foot <Graeme.Foot at touchcut.com>; Richard
>>>>>>> Hacker<ha at igh.de>; etherlab-users at etherlab.org;
>>>>>>> james.benway at gleeble.com
>>>>>>> Subject: Re: [Etherlab-users] Timeout while setting state
>>>>>>> INIT.
>>>>>>>
>>>>>>> Hi,
>>>>>>> I noticed, the correct path with option is: "--enable-sii-
>>>>>>> override=/lib/firmware"
>>>>>>> This way, the master can find my ec_xxx.bin file. But still
>>>>>>> at
>>>>>>> the
>>>>>>> end, slave doesn't respond to go INIT command.
>>>>>>> Here is the dmesg output:
>>>>>>> https://we.tl/t-BGDmNzZv2b
>>>>>>> Best regards,
>>>>>>> Oguz.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>
>>
--
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
More information about the Etherlab-users
mailing list