[Etherlab-users] Timeout while setting state INIT.

Richard Hacker ha at igh.de
Tue Mar 24 09:23:40 CET 2026


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
> 

-- 
Mit freundlichem Gruß / Best regards,
Richard Hacker
--  
-----------------------------------------------------------------------
Richard Hacker, M.Sc.
Entwicklungsingenieur / Development Engineer
ha at igh.de

Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH Gesellschaft für Ingenieurleistungen mbH
Nordsternstraße 66
D-45329 Essen

https://igh.de | https://etherlab.org

Amtsgericht Essen HRB 11500 | USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
Frederik Becker, Dr.-Ing. Siegfried Rotthäuser, Jost Braukmann
-----------------------------------------------------------------------


More information about the Etherlab-users mailing list