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" <[email protected] on behalf of [email protected]> 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 [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
