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

_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Reply via email to