Hello, I am using EtherCAT Version 1.5 (rev. 1824) with RTAI 3.7.1 for controlling a compliant robot arm. The controller is implemented in user space because of licence issues implementing it in kernel space. As mentioned in the feature list, the EtherCAT-Master implementation should be usable with the different realtime implementations RTAI, Xenomai,... and also under standard linux itself. The controller has to work with a frequency of at minimum 1 kHz. I am checking the real cycle times of the controller and I have found out, that the realtime task is not being executed with the desired frequency (1, 2 or 4 kHz). Irregularly the controller task is interrupted for more than 25ms. Using the same controlling code with an internal software model of the robot arm, the controller and the simulation model are running constantly with the desired frequency. Using the EtherCAT-library to control the real hardware leads to a break of hard realtime execution. I commented out everything in the realtime-step-function but these four lines mentioned in the documentation for cyclic operation of EtherCAT: ecrt_master_receive(), ecrt_domain_process(), ecrt_domain_queue(), ecrt_master_send() The scheduler stats of rtai (/proc/rtai/scheduler) are telling me, that there are transitions from hard to soft to hard realtime execution caused by syscalls and the number of syscalls is continuously increasing, if the controller thread is executed. Compared to the simulation model, there are no syscalls breaking hard realtime execution. I analysed the code of the user space library and also the kernel space implementation of the ioctl-calls of the character device /dev/EtherCATx. There are two points which are breaking realtime execution under rtai/lxrt: 1. using ioctl (see http://www.rtai.dk/cgi-bin/gratiswiki.pl?LXRT_FAQs) and 2. using kernel semaphores to lock the above mentioned kernel function calls, which are not locked if they are used in kernel space directly. I commented out the usage of the kernel semaphores in the relating ioctl-functions in kernel space, but that makes no difference that the hard-realtime-thread is pushed back to soft realtime execution. So, why are kernel semaphores being used here? It is mentioned in the documentation that usage of standard kernel semaphores are not sufficient for providing a correct locking mechanism if realtime extensions like rtai and xenomai are used and so the application which has requested the master has to provide the appropriate locking mechanism. Does an implementation of the kernel calls exist which can guarantee hard realtime execution in user space? Or do I have to implement the corresponding LXRT-calls by myself?
Best regards, Jürgen Kunz -- Dipl.-Inform. Jürgen Kunz E-Mail: kunz(at)sim.tu-darmstadt.de FG Simulation, Systemoptimierung Tel.: ++49 (0) 6151-16-70383 und Robotik Fax: ++49 (0) 6151-16-6648 Technische Universität Darmstadt http://www.sim.tu-darmstadt.de Hochschulstr. 10 64289 Darmstadt _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
