[etherlab-users] Ethercat master kernel module warnings

[Dr.-Ing. Wilhelm Hagemeister]

Hello John,

have you tried with the supplied sample "c" code?

Just for your information:
on a recent kernel with RT-Preempt-Patch we run cyclic tasks usually at 
1 kHz with the generic NIC driver without any skipped datagrams.

If you don't use the RT-Preempt-Patch you should not observe regular 
skipped frames if you do not load the machine to much.

If you have skipped frames at regular time intervals there is something 
wrong with your application.

If you have skipped frames randomly it can be cabling (unlikely), a 
misbehaving slave (very unlikely), or non realtime behaviour of your 
application.

Try to measure the time intervals between your cyclic calls.

Try to measure the time interval between "master_send" and 
"master_recieve". The EtherCat frame has to be "back" before you can 
receive it.

One more thing: intelligent NIC's can do interrupt throttling to 
decrease load for the processor. This results in poor realtime 
behaviour. I can remember this has been an issue some time ago. Please 
check the etherlab mailing list...

Regards Wilhelm.

Am 14.12.2015 um 17:24 schrieb John Hubbard:
> 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.
>
>
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>