[etherlab-dev] EtherCAT Master 1.5 & Xenomai

Rob Stocks rjs at computerway.biz
Fri Oct 15 11:21:26 CEST 2010


Firstly, thanks to Etherlab for some great software. This has enabled us to
add EtherCAT support to our application in addition to PROFINET and we now
have a production site up and running with this software and some EtherCAT
Box products from Beckhoff with no problems.

We have made some changes to the code though and would like to submit these
back if possible. The changes we have made are as follows:

* Added support for Xenomai. In particular, memory allocation, semaphores,
RTDM driver model etc. We have done this by adding '#ifdef XENOMAI .. #else
. #endif' blocks to code and by changing the Makefile to accept a XENO=y
parameter which in turn defines XENOMAI. This would be better if it was
moved to the configure script (particularly as it could then locate the
Xenomai includes and libraries) but this is not an area of our expertise. If
compiled with Xenomai support, the driver uses the RTDM model to create a
realtime device rather than the usual character device for communication
with the library. The library then opens this rt device using the Xenomai
RTDM calls. We have created pre-processor wrappers for common functions like
obtaining and releasing semaphores, allocating and freeing memory etc. so
that the software can be ported to other environments more easily.

* Modified the library to obtain slave, PDO and PDO entry names when
performing a bus scan

In addition, we would like to propose/make the following modifications:

* Create a C++ library that can be used instead of the C library. Most of
the work has been done for this since the tool already uses a set of well
structured C++ classes that could be separated out into a library that the
tool then makes use of.

* Modify the C library so that it can obtain information about slaves using
alias and relative position instead of absolute ring position. This is
useful where the application knows (e.g. from a previous bus scan during
commissioning) what devices should be present and would like to query those
devices (e.g. for their names). At present, you have to perform a bus scan
and then attempt to match alias:position with the expected devices to obtain
the absolute ring position. This is a little unnecessary and expensive since
the master already knows this information and even has functions to locate
devices by alias:position rather than absolute ring position but the library
does not provide any functions to do this. I will happily add this
functionality but there is a choice: break the C interface by adding alias
to all the relevant calls (pass zero as the alias to obtain the present
behaviour) or provide a duplicate set of functions with the extra alias
parameter (in this case, what should they be called?).

Finally, we have noticed that our cyclic real time Xenomai task occasionally
overruns. This occurs during the calls to ecrt_master_receive,
ecrt_domain_process, ecrt_domain_queue & ecrt_master_send if for example the
bus has changed. Also, if we have multiple domains and process one much less
often than the other (e.g. a fast analogue input domain and a slower digital
I/O domain), the calls to ecrt_domain_process and ecrt_domain_queue on the
slower domain can take longer than usual and cause overruns (presumable due
to a build-up of datagrams that now need processing). Therefore, it would
appear that there is no advantage in this approach and we may as well call
these functions at the same frequency on all domains. To alleviate the first
of these issues, is there any way of moving the bus scan functionality into
another thread/task so that the cyclic I/O task is not blocked during a bus
scan?


	






More information about the Etherlab-dev mailing list