<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>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:</p>
<blockquote>
<div class="moz-cite-prefix">"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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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."</div>
</blockquote>
<div class="moz-cite-prefix">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?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Best regards,</div>
<div class="moz-cite-prefix">Oguz.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 27-Mar-26 1:30 AM, Graeme Foot
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3654e7ee0d6f4c13828b98678b65b1e1@touchcut.com">
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:etherlab-users-bounces@etherlab.org"><etherlab-users-bounces@etherlab.org></a> On Behalf Of Bilko AS, Oguz Dilmac
Sent: Friday, 27 March 2026 03:37
To: Gavin Lambert <a class="moz-txt-link-rfc2396E" href="mailto:gavin.lambert@tomra.com"><gavin.lambert@tomra.com></a>; Richard Hacker <a class="moz-txt-link-rfc2396E" href="mailto:ha@igh.de"><ha@igh.de></a>; <a class="moz-txt-link-abbreviated" href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.)
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">-----Original Message-----
From: Etherlab-users <a class="moz-txt-link-rfc2396E" href="mailto:etherlab-users-bounces@etherlab.org"><etherlab-users-bounces@etherlab.org></a> On Behalf
Of Bilko AS, Oguz Dilmac
Sent: Wednesday, 25 March 2026 10:56 pm
To: Richard Hacker <a class="moz-txt-link-rfc2396E" href="mailto:ha@igh.de"><ha@igh.de></a>; <a class="moz-txt-link-abbreviated" href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Hi Richard,
Here are the outputs of the commands after a fresh start. No
application is running.
lynca@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@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@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0000
0x98 152
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0001
0x01 1
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0002
0x0001 1
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0004
0x08 8
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0005
0x08 8
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0006
0x08 8
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint8 0x0007
0x0f 15
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0008
0x01cc 460
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
0x0002 2
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
0x0002 2
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
0x0000 0
lynca@lynca:~$ sudo ethercat state -p0 init
lynca@lynca:~$ ethercat slaves
0 0:0 PREOP E Megatec_ESC_NLCH
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
0x0001 1
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
0x0002 2
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
0x0000 0
lynca@lynca:~$ sudo ethercat state -p0 preop
lynca@lynca:~$ ethercat slaves
0 0:0 PREOP + Megatec_ESC_NLCH
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0120
0x0001 1
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0130
0x0002 2
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x0134
0x0000 0
lynca@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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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@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@lynca:~$ ethercat slave
0 0:0 PREOP + Megatec_ESC_NLCH lynca@lynca:~$ ethercat slaves
0 0:0 PREOP + Megatec_ESC_NLCH lynca@lynca:~$ sudo ethercat
state -p0 init lynca@lynca:~$ ethercat slave
0 0:0 PREOP E Megatec_ESC_NLCH lynca@lynca:~$ sudo ethercat
state -p0 preop lynca@lynca:~$ ethercat slave
0 0:0 PREOP + Megatec_ESC_NLCH lynca@lynca:~$ sudo ethercat
reg_read -p0 -tuint32 0x900
0x0af50b04 183831300
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint64 0x910
0x00000051a7927504 350703744260
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x120
0x0001 1
lynca@lynca:~$ sudo ethercat reg_read -p0 -tuint16 0x130
0x0002 2
lynca@lynca:~$
And these are executed while the application is running:
lynca@lynca:~$ sudo ethercat slave
0 0:0 PREOP E Megatec_ESC_NLCH lynca@lynca:~$ sudo ethercat
reg_read -p0 -tuint16 0x120
0x0001 1
lynca@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 (
<a class="moz-txt-link-freetext" href="https://github.com/DSI-Gleeble/ethercat/tree/sii-from-file">https://github.com/DSI-Gleeble/ethercat/tree/sii-from-file</a>).
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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 -------------------+
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">[slave 0 write][slave 0 read]|
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
If you split them into two domains you get:
+ domain 0 -----+ domain 1 ----+
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">[slave 0 write]|[slave 0 read]|
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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 --------------
----
----
--+
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">[slave 0 write][slave 1 write][...]| [slave 0 read][slave 1
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">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:
<a class="moz-txt-link-freetext" href="https://www.ti.com/lit/an/spracj7/spracj7.pdf?ts=1669243747147">https://www.ti.com/lit/an/spracj7/spracj7.pdf?ts=1669243747147</a>
* 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 <a class="moz-txt-link-rfc2396E" href="mailto:odilmac@bilko-automation.com"><odilmac@bilko-automation.com></a>
Sent: Thursday, 19 March 2026 23:49
To: Graeme Foot <a class="moz-txt-link-rfc2396E" href="mailto:Graeme.Foot@touchcut.com"><Graeme.Foot@touchcut.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>
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:
<a class="moz-txt-link-freetext" href="https://we.tl/t-Dj1MtId6LA">https://we.tl/t-Dj1MtId6LA</a>
Best regards,
Oguz.
On 19-Mar-26 1:16 AM, Graeme Foot wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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<a class="moz-txt-link-rfc2396E" href="mailto:odilmac@bilko-automation.com"><odilmac@bilko-automation.com></a>
Sent: Thursday, 19 March 2026 02:33
To: Graeme Foot <a class="moz-txt-link-rfc2396E" href="mailto:Graeme.Foot@touchcut.com"><Graeme.Foot@touchcut.com></a>; Richard
Hacker<a class="moz-txt-link-rfc2396E" href="mailto:ha@igh.de"><ha@igh.de></a>; <a class="moz-txt-link-abbreviated" href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>;
<a class="moz-txt-link-abbreviated" href="mailto:james.benway@gleeble.com">james.benway@gleeble.com</a>
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:
<a class="moz-txt-link-freetext" href="https://we.tl/t-BGDmNzZv2b">https://we.tl/t-BGDmNzZv2b</a>
Best regards,
Oguz.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">--
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
: <a class="moz-txt-link-abbreviated" href="mailto:odilmac@bilko-automation.com">odilmac@bilko-automation.com</a> web site :
<a class="moz-txt-link-freetext" href="http://www.bilko-automation.com">http://www.bilko-automation.com</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre"><a class="moz-txt-link-freetext" href="https://www.youtube.com/@LyncaCNC">https://www.youtube.com/@LyncaCNC</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">--
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
: <a class="moz-txt-link-abbreviated" href="mailto:odilmac@bilko-automation.com">odilmac@bilko-automation.com</a> web site :
<a class="moz-txt-link-freetext" href="http://www.bilko-automation.com">http://www.bilko-automation.com</a> <a class="moz-txt-link-freetext" href="https://www.youtube.com/@LyncaCNC">https://www.youtube.com/@LyncaCNC</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">--
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 : <a class="moz-txt-link-abbreviated" href="mailto:odilmac@bilko-automation.com">odilmac@bilko-automation.com</a> web site :
<a class="moz-txt-link-freetext" href="http://www.bilko-automation.com">http://www.bilko-automation.com</a> <a class="moz-txt-link-freetext" href="https://www.youtube.com/@LyncaCNC">https://www.youtube.com/@LyncaCNC</a>
--
Etherlab-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Etherlab-users@etherlab.org">Etherlab-users@etherlab.org</a>
<a class="moz-txt-link-freetext" href="https://lists.etherlab.org/mailman/listinfo/etherlab-users">https://lists.etherlab.org/mailman/listinfo/etherlab-users</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">
--
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 : <a class="moz-txt-link-abbreviated" href="mailto:odilmac@bilko-automation.com">odilmac@bilko-automation.com</a>
web site : <a class="moz-txt-link-freetext" href="http://www.bilko-automation.com">http://www.bilko-automation.com</a> <a class="moz-txt-link-freetext" href="https://www.youtube.com/@LyncaCNC">https://www.youtube.com/@LyncaCNC</a>
--
Etherlab-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Etherlab-users@etherlab.org">Etherlab-users@etherlab.org</a>
<a class="moz-txt-link-freetext" href="https://lists.etherlab.org/mailman/listinfo/etherlab-users">https://lists.etherlab.org/mailman/listinfo/etherlab-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
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 : <a class="moz-txt-link-abbreviated" href="mailto:odilmac@bilko-automation.com">odilmac@bilko-automation.com</a>
web site : <a class="moz-txt-link-freetext" href="http://www.bilko-automation.com">http://www.bilko-automation.com</a>
<a class="moz-txt-link-freetext" href="https://www.youtube.com/@LyncaCNC">https://www.youtube.com/@LyncaCNC</a></pre>
</body>
</html>