[etherlab-users] yet another datagrams UNMATCHED - DC 0.2ms / 5kHz // igb kernel 3.18

[Gavin Lambert]

The ec_igb driver is relatively new (and only exists in 3.18 in the stable-1.5 branch, although the unofficial default-branch patchset <https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme>  extends this to later kernels), so it’s certainly possible that it has some bugs.

 

But the most likely thing is that your hardware or kernel configuration can’t sustain that cycle time.  Sub-millisecond cycle times are possible with PREEMPT_RT (provided that you are not using ec_generic), but are highly dependent on your hardware (and its general latency) and require a very carefully written realtime loop.  You may have better luck using RTAI or Xenomai, however.

 

Another possibility is that you might need to specify a different shift time in your call to ecrt_slave_config_dc.  If you have the ability to hook a scope to your slave to measure the ECAT SOF vs. SYNC0, this can help to determine if the ECAT frame is arriving with the correct phase – you usually want SOF and SYNC0/SYNC1 to cleanly alternate, not letting it jitter sometimes on one side and sometimes the other.  Check your slave’s documentation for guidelines on specifying the shift time.

 

Another option, if your slave supports it or if you can switch to an alternate slave, is to use oversampling.  In one application I sample data at 4000 Hz with a 1ms ECAT cycle time (PREEMPT_RT with e1000e) by using a slave that is configured to capture 4 samples per ECAT cycle (triggered by the DC sync clock).

 

From: Jürgen Walter • DATATRONiQ
Sent: Tuesday, 13 February 2018 14:23
To: etherlab-users at etherlab.org
Subject: [etherlab-users] yet another datagrams UNMATCHED - DC 0.2ms / 5kHz // igb kernel 3.18

 

Hello list, 

I have been fighting with an ethercat slave (measurement device from imc) over the past week. I got it somewhat (mostly?) working but I am seeing really a lot of the dreaded "datagrams UNMATCHED" in syslog.

My setup is an APU2 (AMD Chipset but "Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)" -  <https://pcengines.ch/apu2.htm> https://pcengines.ch/apu2.htm) with Ubuntu 12.04 and a "low latency" kernel 3.18 installed - to my delight (after doing ./bootstrap.sh) I found the option "--enable-igb" available with "./configure --help" (it was not available on the 3.2 and 3.13 (or some earlier experiments with a newer distro and Kernel 4.4)). I enabled it and after "make && make modules && make install && make modules_install" I can do "/etc/init.d/ethercat start" and the module loads with:

ec_igb 0000:01:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

Next, I have adapted the main.c in "examples/dc_user"

1.	customising the PDO section and inserting my output of "ethercat cstruct"

2.	changing the frequency to: "#define FREQUENCY 5000" (this is so I can get a DC cycle time of 200 microseconds (working fine in TwinCat 3)) 

3.	reading (some of the) mapped PDOs in the cyclic task

4.	customizing "ecrt_slave_config_dc" (fixed DC cycle time, nothing else works with this slave): ecrt_slave_config_dc(sc, 0x0300, 200000, 0, 0, 0);

I can see from the logs that the DC setup succeeds and the slaves goes into OP (it is the only slave, a 1:1 direct connection).
I can also confirm that the PDO exchange works so far because the data I am reading makes sense.

Yet, my syslog essentially gets flooded with those two

EtherCAT WARNING 0: 58 datagrams UNMATCHED!
EtherCAT WARNING: Datagram f66b3b8c (domain0-0-main) was SKIPPED 29 times.

In addition - when leaving the "check_domain_state()" call enabled, I am seeing those (warnings?):

Domain1: WC 0.
Domain1: State 0.
Domain1: WC 1.
Domain1: State 2.
Domain1: WC 0.
Domain1: State 0.
Domain1: WC 1.

When I reduce the "FREQUENCY" back to 1000 the problems pretty much disappear; however, my problem is that I need to run the DC cycle at 200 microseconds (each channel uses PDOs with 10 real/float values - I need to read each channel 5000x per second in order to get all 50.000 measurement samples).

I have also tried this setup on a newer Ubuntu with Kernel 4.4 and the generic driver - the results are essentially the same.

I am really not sure how to proceed from here - should I give the Xenomai a try? Or buy another PCI/Intel network card (PRO/GT - what model works still with the e1000/e drivers?) - or am I in general out of luck because 200us DC cycles are completely unrealistic with the ec_master? 

Any help would be greatly appreciated!! Jürgen 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180213/3f94307c/attachment-0003.htm>