[etherlab-users] Ethercat master kernel module warnings

[John Hubbard]

Matthieu,

Thanks for the hint.  Switching to sleep_until got me closer to the 
expected frequency but didn't do anything for the skipped/missed 
datagrams.  I'll look into using an OS sleep call instead of the 
stdlibc+=11 calls.

Thanks for the suggestion.

On 12/14/2015 09:37 AM, Matthieu Bec wrote:
> 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.