[etherlab-users] EtherCAT stack time requirement per domain is too long

[Graeme Foot]

> -----Original Message-----

> From: Sy Meshkat [mailto:sy.meshkat at dspcg.com]

> Sent: Friday, 12 January 2018 12:42 p.m.

> To: Graeme Foot <Graeme.Foot at touchcut.com>

> Subject: FW: EtherCAT stack time requirement per domain is too long

>

>

> Sorry, it actually takes 400 microseconds --> 8*400 microseconds = 3.2 ms

>

> -----Original Message-----

> From: Sy Meshkat [mailto:sy.meshkat at dspcg.com]

> Sent: Thursday, January 11, 2018 5:39 PM

> To: 'Graeme.Foot at touchcut.com'

> Subject: EtherCAT stack time requirement per domain is too long

>

>

> Dear Graeme,

>

> This is Sy, I supervise Rahul Deshpande with his EtherCAT project. In the

> past, Rahul has written several emails to you and your help has proven

> invaluable.

>

>

> Our EtharCat core in Linux works properly and we use it in a coordinated

> motion control application using multiple Yaskawa Ethercat Sigmas.

>

> In reviewing various timings, the time EtherCAT stack requires to process

> each domain, in our application is about 300 microseconds.  This is too

> long, especially because we have 8 Sigma 5 drives which means it takes 8*300

> microseconds = 3.2 ms to process all domains per cycle!

>

> What was your experience in your application? Did you notice that stack time

> requirement to process a domain was that long?  If so, how could we reduce

> it?

>

> Thanks in advance!

>

> Sy Meshkat





Hi,



(Remember to send or cc to the etherlab users forum.)



We use a Beckhoff CX2020 pc (1.4GHz Celeron single core).  We have machines with up to around 20 axes.  The cycle time is 1000Hz (1ms per cycle).  The Yaskawa axes use 65 bytes of PDO data per axis (I use a few more than just the standard parameters).  I use three domains for the application:

- Yaskawa axes read domain

- Yaskawa axes write domain

- Read/Write domain for all other modules.



My three domains with the 20 odd axes (and various digital and analogue IO) take approximately 30us to perform the following functions:

- ecrt_master_receive()

- ecrt_domain_process() (x3)

- ecrt_domain_state() (x3)

- ecrt_master_state()

- do some funky stuff with my data

- ecrt_domain_queue() (x3)

- ecrt_master_reference_clock_time()

- ecrt_master_sync_slave_clocks()

- ecrt_master_64bit_reference_clock_time_queue()

- ecrt_master_application_time()

- ecrt_master_send()

- some distributed clock calculations



My total processing time per cycle is approximately 160us, so around 16% of my cycle time.  This includes the above the above EtherCAT processing and all logic required to process the data.  It does not include command calls from our external control application, which get processed via the Linux context.





It sounds like you are creating two domains per axis.  If so, you don't need to do this.  You just need one domain per type of function (read, write, read/write) and add the IO from each module as appropriate.



>From memory you are using Xenomi.  What network card driver are you using?  I don't think you can use the generic driver with Xenomi to achieve realtime EtherCAT, you certainly can't with RTAI (which I use).



In RTAI there is a utility you can use (cat /proc/rtai/scheduler | grep 'transitions') that will tell you if you are making any syscalls from your realtime context.  If you do so, then you drop out of realtime and are running code under the Linux context, which can take any amount of time.  Check if Xenomi has a similar utility.



Check that you have a stable realtime system with as little jitter as possible.



Other than that, put timers around various sections of the code and see if you can pinpoint any particularly slow functions.





Here is an example of the statistics page from our application for a machine running 16 axes:

[cid:image001.png at 01D38DF5.579569B0]



I've circled the EtherCAT processing time in red and the axis specific logic time in green.





Regards,
Graeme.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180114/6c798b65/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 62567 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180114/6c798b65/attachment-0003.png>