[Etherlab-users] Timeout while setting state INIT.

Bilko AS, Oguz Dilmac odilmac at bilko-automation.com
Wed Mar 18 14:33:12 CET 2026


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.


On 18-Mar-26 2:31 PM, Bilko AS, Oguz Dilmac wrote:
>
> Hi Graeme, James,
>
> I tried the "enable-sii-override" option just in case. But I'm not 
> sure if I did it correctly. Here is what I did:
>
> * I installed the master version from Mr James Benway: 
> https://github.com/DSI-Gleeble/ethercat/tree/sii-from-file. I used the 
> "--enable-sii-override=/lib/firmware/ethercat" option.
>
> * I created the ethercat folder under /lib/firmware
>
> * I copied the binary file (ec_6167656d_00000000.bin) from twincat to 
> /lib/firmware/ethercat folder.
>
> When I checked the debug messages, I noticed that master tries to open 
> the ethercat/ec_6167656d_00000000.bin but couldn't find it. This file 
> is copied under /lib/firmware/ethercat.
>
> Then I checked the config.log. It seems, the path is correct:
>
> ...
>
> configure:19137: checking whether to assign the SII to PDI
> configure:19163: result: yes
> configure:19174: checking whether to load SII locally if available
> configure:19210: result: yes, from /lib/firmware/ethercat
>
> ...
>
> Why do you think the master can't find the file?
>
> By the way, this is the dmesg output:
>
> [   49.650743] ec_r8169 0000:02:00.0 enp2s0: Link is Down
> [   51.697773] EtherCAT 0: Master debug level set to 1.
> [   52.336230] ec_r8169 0000:01:00.0 ecm0 (uninitialized): Link is Up 
> - 100Mbps/Full - flow control rx/tx
> [   53.255968] EtherCAT 0: Link state of ecm0 changed to UP.
> [   53.257011] EtherCAT 0: 1 slave(s) responding on main device. 
> Re-scanning on next possibility.
> [   53.257014] EtherCAT 0: Slave states on main device: INIT.
> [   53.257015] EtherCAT 0: Re-scanning now.
> [   53.257063] EtherCAT DEBUG 0: Sending broadcast-write to measure 
> transmission delays on main link.
> [   53.257098] EtherCAT DEBUG 0: 1 slaves responded to delay measuring 
> on main link.
> [   53.257099] EtherCAT 0: Scanning bus.
> [   53.257100] EtherCAT DEBUG 0: Scanning slave 0 on main link.
> [   53.257233] EtherCAT DEBUG 0-0: Slave has the System Time register.
> [   53.257300] EtherCAT DEBUG 0-0: Assigning SII access to EtherCAT.
> [   53.296413] EtherCAT DEBUG 0-0: Trying to load SII firmware: 
> ethercat/ec_6167656d_00000000_00000000.bin
> [   53.296414] EtherCAT DEBUG 0-0: then: ethercat/ec_6167656d_00000000.bin
> [   53.296444] EtherCAT DEBUG 0-0: request_firmware_direct: 
> ethercat/ec_6167656d_00000000_00000000.bin.
> [   53.301871] EtherCAT DEBUG 0-0: request_firmware_direct: 
> ethercat/ec_6167656d_00000000.bin.
> [   53.301886] EtherCAT DEBUG 0-0: SII firmware file not found; 
> reading SII data from slave.
> [   53.306417] EtherCAT DEBUG 0-0: Found category type 10 with size 
> 401. Proceeding to offset 467.
> [   53.311433] EtherCAT DEBUG 0-0: Found category type 30 with size 
> 16. Proceeding to offset 485.
> [   53.316425] EtherCAT DEBUG 0-0: Found category type 40 with size 2. 
> Proceeding to offset 489.
> [   53.321430] EtherCAT DEBUG 0-0: Found category type 41 with size 
> 16. Proceeding to offset 507.
> [   53.326411] EtherCAT DEBUG 0-0: Found category type 50 with size 
> 160. Proceeding to offset 669.
> [   53.331403] EtherCAT DEBUG 0-0: Found category type 51 with size 
> 160. Proceeding to offset 831.
> [   53.336482] EtherCAT DEBUG 0-0: Found category type 60 with size 
> 12. Proceeding to offset 845.
> [   55.421478] EtherCAT DEBUG 0-0: Slave announces to support CoE, FoE.
> [   55.421541] EtherCAT DEBUG 0-0: Unknown category type 0x003C.
> [   55.421543] EtherCAT DEBUG 0-0: Slave is not in the state to do 
> mailbox com (INIT), setting to PREOP.
> [   55.421544] EtherCAT DEBUG 0-0: Configuring...
> *[   55.421940] EtherCAT DEBUG 0-0: Now in INIT.*
> [   55.421942] EtherCAT DEBUG 0-0: Clearing FMMU configurations...
> [   55.422051] EtherCAT DEBUG 0-0: Clearing sync manager configurations...
> [   55.422135] EtherCAT DEBUG 0-0: Clearing DC assignment...
> [   55.422205] EtherCAT DEBUG 0-0: Configuring mailbox sync managers...
> [   55.422206] EtherCAT DEBUG 0-0: SM0: Addr 0x1000, Size 1024, Ctrl 
> 0x26, En 1
> [   55.422207] EtherCAT DEBUG 0-0: SM1: Addr 0x1400, Size 1024, Ctrl 
> 0x22, En 1
> [   55.422277] EtherCAT DEBUG 0-0: Assigning SII access to PDI.
> *[   55.431498] EtherCAT DEBUG 0-0: Now in PREOP.*
> [   55.431500] EtherCAT DEBUG 0-0: Assigning SII access back to EtherCAT.
> [   55.431570] EtherCAT DEBUG 0-0: Finished configuration.
> [   55.431571] EtherCAT DEBUG 0-0: Scanning PDO assignment and mapping.
> [   55.431572] EtherCAT DEBUG 0-0: Reading PDO assignment of SM2.
> [   55.431573] EtherCAT DEBUG 0-0: Uploading SDO 0x1C12:00.
> [   55.431575] EtherCAT DEBUG 0-0: Upload request:
> [   55.431575] EtherCAT DEBUG: 00 20 40 12 1C 00 00 00 00 00
> [   55.441795] EtherCAT DEBUG 0-0: Upload response:
> [   55.441797] EtherCAT DEBUG: 00 30 4F 12 1C 00 01 00 00 00
> [   55.441802] EtherCAT DEBUG 0-0: Uploaded data:
> [   55.441803] EtherCAT DEBUG: 01
> [   55.441803] EtherCAT DEBUG 0-0: 1 PDOs assigned.
>
> I noticed, in the log there are messages stating it is in the INIT and 
> PREOP states. Is this the slave device?
>
> Best regards,
>
> Oguz.
>
>
> On 18-Mar-26 1:04 AM, Graeme Foot wrote:
>> Hi Oguz,
>>
>> You can check if you have the patch by looking in configure.ac.  If it has the "--enable-sii-override" option you have it and you can select to use it with your preferred firmware directory.
>>
>> Re below:
>> I didn't notice any major differences between the generated and downloaded SII files.
>>
>> Regards,
>> Graeme.
>>
>> -----Original Message-----
>> From: Etherlab-users<etherlab-users-bounces at etherlab.org> On Behalf Of Bilko AS, Oguz Dilmac
>> Sent: Wednesday, 18 March 2026 02:59
>> To: Richard Hacker<ha at igh.de>;etherlab-users at etherlab.org
>> Subject: Re: [Etherlab-users] Timeout while setting state INIT.
>>
>> Hi Richard,
>>
>> Here is the output of "ethercat slave -v" command:
>>
>> ~$ 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             -    316752436    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
>>
>> Also you can check the "ethercat sii_read" command output and the twincat sii file as binary files. I think the twincat version doesn't have the PDO mapping.
>>
>> https://we.tl/t-0aPRUmH6FG
>>
>> By the way, I tried to write the same registers I mentioned on my previous mails. Just before activating the master. It didn't affect anything.
>>
>> One more thing I noticed is, usually if I try to configure the device second time without a power cycle, the vendor ID at the response of the "ethercat slaves" command becomes 0.
>>
>> So far the vendor just claims the different devices (The one works perfectly with IgH and the one which doesn't reply to INIT command) are same in sense of ethercat communication.
>>
>> I would really appreciate if you can notice something.
>>
>> Best regards,
>>
>> Oguz.
>>
>>
>>
>> On 17-Mar-26 3:12 PM, Richard Hacker wrote:
>>> 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
>>>>>    
>>>>>    
>>>>    
>> --
>> 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

-- 
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/20260318/4a6eec24/attachment-0001.htm>


More information about the Etherlab-users mailing list