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

[Jürgen Walter • DATATRONiQ]

Hello Gavin,

many thanks for the detailed reply!

On 13 Feb 2018, at 5:04, Gavin Lambert wrote:

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

I see- will get another Intel card (although compatible ones (kernel 
driver e1000, e1000e) seem to be hard to come by these days) and try 
with anther kernel driver.

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

Understood -will try first an RT kernel (I read that Debian brings out 
of the box support for linux-image-rt-....deb - will try that first; 
else going to recompile)

> 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.
that is a bit beyond my abilities right now - however, the slave works 
fine under Twincat using 200us as cycle time, and 0 for shift (but that 
is just in the Twincat GUI - who knows if Twincat actually negotiates / 
adapts some phase shift behind the scenes?)

> 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).
Yes, this one already does use oversampling: the measurement device 
(slave) generates 50.000 samples per second (actually: 8x because 8 
channels) - the slaves stuffs 10 samples into one PDO so I have to make 
sure to read/exchange the PDO 5.000x per second (if I understand 
correctly, this is how the vendor of the slave calculates the 200us)


Again, many thanks for your help - I will report back with my results!! 
Jürgen