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@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
