[etherlab-users] yet another datagrams UNMATCHED - DC 0.2ms / 5kHz // igb kernel 3.18
Jürgen Walter • DATATRONiQ
jw at datatroniq.com
Tue Feb 13 10:01:43 CET 2018
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
> 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!!
More information about the Etherlab-users