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!!
etherlab-users mailing list