[etherlab-users] Ethercat master kernel module warnings

[John Hubbard]

Wilhelm,

Your comment "If you see skipped frames at regular time intervals there 
is something wrong with your application" was spot on.  The problem was 
with my application.  I was doing the ecrt_domain_queue and 
ecrt_master_send twice per cyclic task. After removing the duplicate 
queue/send the errors are gone.

Thanks a bunch.

On 12/14/2015 10:13 AM, Dr.-Ing. Wilhelm Hagemeister wrote:
> 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
>>
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users


-- 
-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.