From gavin.lambert at tomra.com Mon May 4 01:14:14 2026 From: gavin.lambert at tomra.com (Gavin Lambert) Date: Sun, 3 May 2026 23:14:14 +0000 Subject: [Etherlab-users] User mode "Register" access methods In-Reply-To: References: <31e3220fa16f18061a400b8e18f54fbc79200f00.camel@igh.de> <078f9c8da79b713bf61e0459333de18fde2d4823.camel@igh.de> <471f8226-0853-49c5-9daa-cf6c15ca0ea2.240fbd61-bfd8-4700-b5db-6dad64766134.1ec8adc7-3c95-4de5-ab2b-7a23c762448b@emailsignatures365.codetwo.com> <471f8226-0853-49c5-9daa-cf6c15ca0ea2.7fff08e7-30d4-419a-bb0e-223e1b91003f.a84046a2-ee69-43ff-a3b6-592b08cfbfe6@emailsignatures365.codetwo.com> <471f8226-0853-49c5-9daa-cf6c15ca0ea2.f428c1e8-9b65-4082-8b87-d0c1551d6566.7214a858-87e9-4aca-a203-ee3c4a6a2cca@emailsignatures365.codetwo.com> <471f8226-0853-49c5-9daa-cf6c15ca0ea2.ee6da8dd-532c-43a9-8cae-3b2dd5aa5e20.d2d5246d-df2a-4e89-97ed-e662ebf28501@emailsignatures365.codetwo.com> <471f8226-0853-49c5-9daa-cf6c15ca0ea2.39ba2b53-b46d-442f-a7a2-431de4bfaa97.8fdd5192-4160-45f8-8422-31a18ea03c8b@emailsignatures365.codetwo.com> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png Type: image/png Size: 6455 bytes Desc: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg Type: image/jpeg Size: 10123 bytes Desc: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg Type: image/jpeg Size: 10214 bytes Desc: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg Type: image/jpeg Size: 2256 bytes Desc: icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg Type: image/jpeg Size: 10218 bytes Desc: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg Type: image/jpeg Size: 10303 bytes Desc: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg URL: From odilmac at bilko-automation.com Thu May 21 12:20:10 2026 From: odilmac at bilko-automation.com (Bilko AS, Oguz Dilmac) Date: Thu, 21 May 2026 13:20:10 +0300 Subject: [Etherlab-users] Timeout while setting state INIT. In-Reply-To: <3654e7ee0d6f4c13828b98678b65b1e1@touchcut.com> References: <404175ea-4a0c-40b8-9693-2ef33690f08e@bilko-automation.com> <7d5238a8-47e2-4605-9182-248f38c1d99b@bilko-automation.com> <747f2d3d-6471-4533-b71b-8cc37e52277d@bilko-automation.com> <24c1d641dfc84ad78250bd7b982d1e41@touchcut.com> <1518071f919fe580507bf1ef27b9380fbc3980c6.camel@igh.de> <8e7c910ebc08d43deacc0545b7a4a1b83d6d65c7.camel@igh.de> <7664f092-9986-43a3-8088-0e7f0e1824d9@bilko-automation.com> <3654e7ee0d6f4c13828b98678b65b1e1@touchcut.com> Message-ID: <0b18a310-f085-4377-b842-22df5ee24af5@bilko-automation.com> Hello, We are still investigating the problem with the device. We gave the vendor of the device an industrial PC with IgH master 1.6.7 installed. You can find his remarks below: "I made some investigations but do not have exact reason for a failure. I suppose there are two main reasons. The first one is a timing. The twincat switches the states of EtherCAT with much larger time between commands than IGH. The second reason seems to me the IGH does not check current state before trying to order the next state. I have modified the firmware to check what happens with requests from the point of the firmware and I see that some requests PREOP -> SAFEOP are denied but the master does not wait and goes to OP. So the slave is stucking in PREOP. If this happens there are no recovery efforts. The IGH master also send much more commands per second than twincat. It creates approximately 5 times larger wireshark log at same time than twincat. I observed up to 5 state change requests per millisecond. It will definitely overload our optics. So I observe that sometimes the head goes to OP mode but sometimes not. In any case with both old and new firmware the motor does not move. Could you check you code if there is a proof of current state by switching to the new state? A way to stay simple is add delays of 50 milliseconds between new state requests and always start with INIT state." I thought the Igh master already checking the current state. But some how, Vendor come across to a situation, that it doesn't check. Do you have a suggestion? Also can I add some extra time between state changes? Best regards, Oguz. On 27-Mar-26 1:30 AM, Graeme Foot wrote: > Hi Oguz, > > We have made our own slave with an Infinion XMC 4800 controller. It's a good chip with no issues I know of (so the domain layout won't be an issue), depending on their firmware implementation of course. > > A product code of zero is allowed, it's just unusual. It may be the first/only ethercat slave they make. > > Since they have FoE available, that may mean they've implemented the ability to update the firmware. You could request the firmware file and see if re-applying it helps. Otherwise also see if you can revert to the older firmware. > > Regards, > Graeme. > > PS Here's my cheat sheet for applying firmware updates in TwinCat: > > Refer to the modules documentation for specific steps, but in general they should be: > - Start the system in FreeRun mode > - Get the required *.efw firmware file for the module > - Select the module in the device list tree > - Check the current Product/Revision (EtherCAT tab) > - Select the Online tab > - Select Init button > - Select Bootstrap button > - Check that the Current State is BOOT (State = 3) > - Select the Download... button > - Select the .efw file > - Wait for the download to complete > - Select the Init button > - Select the Op button (Note: if not in FreeRun mode you will get an error) > - Repower the module > > > -----Original Message----- > From: Etherlab-users On Behalf Of Bilko AS, Oguz Dilmac > Sent: Friday, 27 March 2026 03:37 > To: Gavin Lambert; Richard Hacker;etherlab-users at etherlab.org > Subject: Re: [Etherlab-users] Timeout while setting state INIT. > > Hi Again, > > I talked to vendor this morning. He said they are using Infinion XMC > 4800 series controller with bechoff slave stack. > > He also said that, they didn't change anything (Chip, stack) regarding to basic communication. They only added a few new commands in FoE access. I don't think this could a cause a problem. > > I forget to ask about the product code but even in the XML file it is 0. > And also the working device had it 0 too. So I don't think this could cause any problem either. > > I will try to get SII file?and a wireshark trace?from the working slave. > > Best reagards, > > Oguz. > > > On 26-Mar-26 5:53 AM, Gavin Lambert wrote: >> The command trace that Richard had you try seems to indicate that the >> slave did manage the INIT -> PREOP transition but is refusing a >> subsequent PREOP -> INIT transition, without giving any error code. >> (Though also check the syslog around the time that you issue the >> "ethercat state" command -- some versions of the master will >> automatically acknowledge and clear the error code register, so the >> syslog is the only place you'll see it.) >> >> Slaves are pretty much always required to accept any state -> INIT without error, and the configuration shouldn't be a factor because the point of going to INIT is to tell the slave that you want to reconfigure fundamental communication properties. >> >> This might be working coincidentally in TwinCAT because it doesn't happen to issue that particular transition sequence during the test, but it is something that even TwinCAT will request at some point in the network/application lifecycle. >> >> You can try asking the vendor for their EtherCAT Conformance Test Tool report (make sure it's for the same model/revision that you're using) -- they're required to test their devices, and I'd be surprised if a device that failed something so basic could pass as conformant. Or send the device back to the vendor as faulty and try another one; maybe it was just a bad firmware in that particular device or batch. >> >> The device reporting itself as product code 0x00000000 seems highly suspicious, although I don't think it's technically illegal. >> >> If you have a working device from the same family, have you tried >> fetching the on-device SII from both and comparing? Differences >> aren't necessarily problematic, but might be interesting. An >> incorrect SII or firmware could cause the device to misbehave, but in >> this case it would not help to soft-override the SII on the master >> side as that patch does; you'd have to install a correct SII or >> firmware into the device itself. (It may not be safe to use the >> working SII on the non-working device, however, especially if they are >> from different revisions -- doing so might brick the device or worse.) >> >>> -----Original Message----- >>> From: Etherlab-users On Behalf >>> Of Bilko AS, Oguz Dilmac >>> Sent: Wednesday, 25 March 2026 10:56 pm >>> To: Richard Hacker;etherlab-users at etherlab.org >>> Subject: Re: [Etherlab-users] Timeout while setting state INIT. >>> >>> 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 >>>>>>>>> Sent: Thursday, 19 March 2026 23:49 >>>>>>>>> To: Graeme Foot; >>>>>>>>> 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 >>>>>>>>>> Sent: Thursday, 19 March 2026 02:33 >>>>>>>>>> To: Graeme Foot; Richard >>>>>>>>>> Hacker;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 >>> >>> >>> -- >>> Etherlab-users mailing list >>> Etherlab-users at etherlab.org >>> https://lists.etherlab.org/mailman/listinfo/etherlab-users > -- > 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 > > > -- > Etherlab-users mailing list > Etherlab-users at etherlab.org > https://lists.etherlab.org/mailman/listinfo/etherlab-users -- 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: From fp at igh.de Thu May 21 15:16:41 2026 From: fp at igh.de (Florian Pose) Date: Thu, 21 May 2026 15:16:41 +0200 Subject: [Etherlab-users] Timeout while setting state INIT. In-Reply-To: <0b18a310-f085-4377-b842-22df5ee24af5@bilko-automation.com> References: <404175ea-4a0c-40b8-9693-2ef33690f08e@bilko-automation.com> <7d5238a8-47e2-4605-9182-248f38c1d99b@bilko-automation.com> <747f2d3d-6471-4533-b71b-8cc37e52277d@bilko-automation.com> <24c1d641dfc84ad78250bd7b982d1e41@touchcut.com> <1518071f919fe580507bf1ef27b9380fbc3980c6.camel@igh.de> <8e7c910ebc08d43deacc0545b7a4a1b83d6d65c7.camel@igh.de> <7664f092-9986-43a3-8088-0e7f0e1824d9@bilko-automation.com> <3654e7ee0d6f4c13828b98678b65b1e1@touchcut.com> <0b18a310-f085-4377-b842-22df5ee24af5@bilko-automation.com> Message-ID: <70cea1c50de26d045322f1d60bee2a158d4ed48e.camel@igh.de> Hello, some comments on this: Am Donnerstag, dem 21.05.2026 um 13:20 +0300 schrieb Bilko AS, Oguz Dilmac: > > > "I made some investigations but do not have exact reason for a > > failure. I suppose there are two main reasons. The first one is a > > timing. The twincat switches the states of EtherCAT with much > > larger time between commands than IGH. The second reason seems to > > me the IGH does not check current state before trying to order the > > next state. I have modified the firmware to check what happens with > > requests from the point of the firmware and I see that some > > requests PREOP -> SAFEOP are denied but the master does not wait > > and goes to OP. So the slave is stucking in PREOP. If this happens > > there are no recovery efforts. When requesting an AL state change the master sends exactly one request to the command register 0x0120 and then starts to query 0x0130 for the result. It only continues if the AL state change is successful, otherwise it marks the slave with an error flag and continues with the next one. It never proceeds with the next AL state if the last state change was not successful. > > The IGH master also send much more commands per second than > > twincat. It creates approximately 5 times larger wireshark log at > > same time than twincat. I observed up to 5 state change requests > > per millisecond. It will definitely overload our optics. It works synchronous to your application cycle, so if your application runs with 5 kHz, there will be at most 5000 queries of 0x0130 per second, usually less, because the master state machine runs asynchronously. > > So I observe that sometimes the head goes to OP mode but sometimes > > not. In any case with both old and new firmware the motor does not > > move. > > > > Could you check you code if there is a proof of current state by > > switching to the new state? A way to stay simple is add delays of > > 50 milliseconds between new state requests and always start with > > INIT state." On configuration, the master always starts with the INIT state. In the standard there is no limit on how fast register reads shall happen. > > > > I thought the Igh master already checking the current state. But some > how, Vendor come across to a situation, that it doesn't check. Do you > have a suggestion? Also can I add some extra time between state > changes? No, it always checks for the state change.? If the problem persists, please try with 1.6.9, a native Ethernet driver and open a ticket on gitlab.com/etherlab.org/ethercat with a minimal example application. -- Mit freundlichem Gru? / Best regards, Florian Pose Dipl.-Ing. (FH) Florian Pose Leitung Automatisierung / Lead Automation Mail: fp at igh.de | Tel.: +49 201 36014-13 Ingenieurgemeinschaft IgH Gesellschaft f?r Ingenieurleistungen mbH Nordsternstra?e 66 D-45329 Essen Member of Axxeron Group [1] igh.de |EtherLab [2] |LinkedIn [3] Amtsgericht Essen | HRB 11500 | USt-Id.-Nr.: DE 174 626 722 Gesch?ftsf?hrung: Frederik Becker, Dr.-Ing. Siegfried Rotth?user, Jost Braukmann [1] Member of Axxeron Group https://www.axxeron.de/ [2] EtherLab https://etherlab.org/ [3] LinkedIn https://de.linkedin.com/company/igh-gmbh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part URL: From ha at igh.de Fri May 22 10:57:37 2026 From: ha at igh.de (Richard Hacker) Date: Fri, 22 May 2026 10:57:37 +0200 Subject: [Etherlab-users] User mode "Register" access methods In-Reply-To: References: <31e3220fa16f18061a400b8e18f54fbc79200f00.camel@igh.de> <078f9c8da79b713bf61e0459333de18fde2d4823.camel@igh.de> Message-ID: <21057ee2d7adce1664d61dc3b6ebd62ad628acaf.camel@igh.de> Unfortunately this feature is not implemented in our master. And neither do you have access to this ID-Request bit in AL Control (0x120) using direct register access because the master assumes exclusive control over this register and will either negate your effoerts or be confused by it. You have 2 options: * implement this feature yourself and send us a pull request * request this feature from us ;) - Richard On Thu, 2026-04-30 at 14:50 +0000, Moebius, Volker wrote: > > Uff, you are using a pooly documented feature where AL Control bit > > 6 > > (0x120.5) is used to request an id from the slave, with the slave > > responding in AL > > Status bit 6 (0x130.5) and putting some value in AL Status Code > > (0x134). This is > > very crooked in my opinion. > > I asked the developers of our slave device about the implementation > of the slave ID. > It's according to the document "ETG. 1020 Protocol Enhancements", > Section 21.4.1. > "Requesting ID - Complex SubDevice with application microcontroller > and ID-Selector", > where the procedure of querying the SubDevice ID by the AL Control > register 0x0120 > is defined. (Unfortunately, I haven't been aware of this document so > far. I'm not > familiar with the EtherCAT protocol.) > > > > This feature is currently not supported by our master, although it > > is not impossible > > to implement such an `id_request` feature. > > > > The reason: AL Control (0x120) is entirely under master control. > > You cannot > > meddle with this register from behind the scenes to manipulate bit > > 6. Hence your > > observation that it function is "time critical". You had to be fast > > so the master > > does not screw your work ;) > > When is the master using this AL Control register? - I assume that an > implementation > of an `id_request` feature would require to synchronize the necessary > register accesses > (0x120, 0x130, 0x134) with those executed by the master for other > reasons, > wouldn't it? Could you give me a hint in which source code module the > AL Control > register is possibly managed? > > Is there a mechanism to "lock" the accesses to the AL Control > register by the public > API of the EC master? > > > > The standard way of implementing this "ID" feature would be either > > to set this > > value in 0x012 (Configured station alias) or better, put it in a > > PDO -- then it > > supports on-the-fly DIP switch changes, which, in fact, it really > > is. You could also > > implement it with a read-only SDO, but SDO's are typically master > > to slave > > communication channel, used to configure a slave once-off before > > entering OP. > > I think that changing the slave device is unfortunately no option, > especially > because there are already devices installed in the field. > > . -- 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 -----------------------------------------------------------------------