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