[Etherlab-users] Timeout while setting state INIT.
Richard Hacker
ha at igh.de
Tue Mar 17 13:12:33 CET 2026
Hi Oguz
Our ethercat master does not support "SII firmware injection". We
rather work according to the maxime: fix the slave.
Although we focus on Beckhoff slaves, we have worked with many
different slave vendors in the past and have yet to encounter a slave
with a behaviour like yours.
We have encountered slaves with a broken SII in the past. Usually we
would confront the vendor. If that didn't work, we fixed it and flashed
the slave ourselves. But that requires intimate knowledge of ethercat
slave implementation beyond that of a regular slave user.
I am not convinced that you have an SII problem. What does
ethercat slave -v
report when you have just plugged in the bus and before starting your
application (i.e. idle mode)?
If there is sensible output from that command, your SII is OK.
Richard
On Tue, 2026-03-17 at 10:56 +0300, Bilko AS, Oguz Dilmac wrote:
>
> Hi Richard and Graeme,
>
> Richard, do you know if the feature Graeme mentioned is included in
> official branch?
>
> And thank you Graeme for your message. What should I check if the
> version I used has this patch? It was some time ago when my colleague
> created an image of the system, and I'm not sure where is the source
> code of the EtherCAT master that was used.
>
> Best regards,
>
> Oguz.
>
> On 15-Mar-26 11:28 PM, Graeme Foot wrote:
>
>
> >
> > Hi Oguz,
> >
> > I haven’t looked at all closely to the issue (and a couple of
> > emails got blocked by our spam/virus filter), but if you suspect
> > that the slaves SII information is incorrect then you can try
> > supplying the SII information yourself, rather than the master
> > downloading if from the slave. If that then works, you can check
> > for the differences between the SII on the slave and the data
> > provided by the esi file. If confirmed you can request the vendor
> > provides an update for the slave with the correct SII information
> > (or continue using the manual SII file).
> >
> > We use quite an old EtherLab master with patches to allow loading
> > your own SII file instead of the master downloading it from the
> > slave (from gavinl’s patchset “0001-load-sii-from-file.patch”). I
> > don’t know what’s available in your master configuration, but in
> > ours we copy the SII file to “/lib/firmware/ethercat”
> >
> > To create an SII file:
> > * Start a new TwinCAT project (TwinCAT XAE Project (XML Format))
> > * Under I/O, Devices add an EtherCAT Master device
> > * If you don’t have the correct esi (.xml) file loaded: copy the
> > slaves esi (.xml) file into:
> > C:\TwinCAT\3.1\Config\Io\EtherCATSelect the TwinCAT, EtherCAT
> > Devices, Reload Device Descriptions menu option
> > * Add you EtherCAT slave to the EtherCAT master device
> > * Open your slave
> > * Select the EtherCAT tab
> > * Select Advanced Settings...
> > * Select the ESC Access, E2PROM, Hex Editor item
> > * Confirm the SII contains the expected values (for Vendor ID ,
> > Product Code etc)
> > * Select the Write to File... button
> > * Save with a filename in the format
> > “ec_{vendor_id_hex}_{product_code_hex}[_{revision_hex}].bin” The
> > revision part is optional.e.g.: ec_00000539_02200001_00010000.bin
> >
> > Regards,
> > Graeme.
> >
> > From: Etherlab-users <etherlab-users-bounces at etherlab.org> On
> > Behalf Of Bilko AS, Oguz Dilmac
> > Sent: Saturday, 7 March 2026 02:30
> > To: Richard Hacker <ha at igh.de>; etherlab-users at etherlab.org
> > Subject: Re: [Etherlab-users] Timeout while setting state INIT.
> >
> >
> >
> > 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
> >
> >
>
--
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