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

Reply via email to