[etherlab-users] Ethercat master kernel module warnings

[Matthieu Bec]

Hello John,

not sure this is your issue, but I went though something very similar. Read the c++11 ref. closely:

- sleep_until "the clock tied to sleep_time is used"
vs.
- sleep_for "a steady clock is used to measure the duration"

Try replace sleep_for with a sleep_until and chrono time tied to your high resolution clock.


c++11 makes no guarantees how sleep is implemented (the use of clocknanosleep with gnu is autodetected at config time, IIUC)
I'd personally recommend to use OS calls rather than portable stdlibc++11 for real-time.

Regards,
Matthieu


On 12/14/15, 8:24 AM, "etherlab-users on behalf of John Hubbard" <etherlab-users-bounces at etherlab.org on behalf of jhubbard at noao.edu> wrote:

Hello,

I'm working on a proof of concept application using the IgH EtherCAT master however I'm having some problems.  Specifically I'm seeing unmatched and skipped datagram packet warnings coming out of the kernel module: 

====================================================
Dec 11 13:26:31 lyot kernel: [878188.716201] EtherCAT WARNING: Datagram ffff88032e383558 (domain0-0-main) was SKIPPED 21 times.
Dec 11 13:26:31 lyot kernel: [878189.443671] EtherCAT WARNING 0: 20 datagrams UNMATCHED!
Dec 11 13:26:32 lyot kernel: [878189.769889] EtherCAT WARNING: Datagram ffff88032e383558 (domain0-0-main) was SKIPPED 21 times.
Dec 11 13:26:32 lyot kernel: [878190.444575] EtherCAT WARNING 0: 20 datagrams UNMATCHED!
====================================================
Based on the mailing list and the documentation PDF I believe that the problem is related to attempting to run the cyclic task too quickly.  I'm running the cyclic task in userland at ~20Hz (50ms delays) on Ubuntu 14.04 with the 3.16.0-55 kernel.  The
 master is relying on the generic NIC driver to control a 4 port Intel 85271EB PCIe card.  Even slowing way down to 5 seconds I still see the occasional "SKIPPED 1 times" message.  The manual suggests that the theoretical cyclic rate should be many orders of
 magnitude faster.  I realize that the theoretical rate is theoretical, but I would have hoped a cyclic task of 20Hz~200Hz to be achievable with the generic NIC driver. 


In short my application (after setting up the master and domain) is doing:

ecrt_master_receive
ecrt_domain_process
// read process data
// calculations
// write process data
ecrt_domain_queue
ecrt_master_send



So my question are:
Has anyone else seen similar problems with unmatched/skipped datagrams even at very low cyclic task rates?
What sort of frequencies should I expect on a non rt-kernel, with a userland app, and the generic NIC driver?
Does anything look obviously wrong with my attached code?  (Be gentle I'm primarily a non real time Java programmer). 


In case it helps my end goal is to replace the discontinued Spectracom TSync PCIe PTP DIO card with a 'block' of Beckhoff modules that provide the same input timestamping, and output match time functionality.  I'm
 currently working with an EK1100 (EtherCat coupler), EL1252 (24v input w/time stamp), EL2252 (24v output w/time stamp), and an EL6688 (PTP module).  When all done everything will be controlled by a userland app running on a CentOS 7 system with standard
 RHEL/CentOS 7 kernel.  At this point I'm still just trying to familiarize myself with the API and get a basic proof of concept application running. 


I have been partly successful reading the input states, and rising/falling latch times from the EL1252.  I have not yet had success with the output module EL2252.  I'll put out another email asking for help with that one.  I haven't even tried to work with
 the EL6688 module.  


Thanks in advance  


-- 
-john

To be or not to be, that is the question
                2b || !2b
(0b10)*(0b1100010) || !(0b10)*(0b1100010)
        0b11000100 || !0b11000100
        0b11000100 ||  0b00111011
               0b11111111
255, that is the answer.