Re: [Etherlab-users] [etherlab-users] Compatibility with kernel 5.x

[Jürgen Walter • DATATRONiQ]

Hello Niko,

we solved the memory leak for our project like so:

Problem:


From: Michael Reeder 
To: etherlab-users@etherlab.org
Subject: [etherlab-users] unofficial ec_igb driver for kernel 4.19 
from Gavin Lambert likely leaks memory

Date: Tue, 14 Jan 2020 12:01:15 +0100

Hi All,

we are using the Etherlab master with the newest patches from Gavin 
Lambert (changeset 12:8ea39404a2e8, 
http://hg.code.sf.net/u/uecasm/etherlab-patches/rev/8ea39404a2e8 ) 
which include a native ec_igb driver for kernel 4.19.


Unfortunately I found that when starting the Etherlab master with this 
driver, free memory on the system is constantly decreasing. This 
doesn't happen when the generic driver is used we assume the igb 
driver has some memory leak.


Did anybody also uses this driver and experienced the same behavior?



Solution:


From: Michael Reeder 
To: Gavin Lambert , Gary Grobe 
, etherlab-users@etherlab.org

Subject: Re: [etherlab-users] ec_igb memory leak?
Date: Fri, 13 Mar 2020 09:37:55 +0100

Hi,

I had the same issue with the 4.19 ec_igb driver.
When comparing the sources with 4.4 it turned out that a line is 
missing in `devices/igb/igb_main-4.19-ethercat.c`


8475| /* retrieve a buffer from the ring */
8476| if(adapter->ecdev) {
8477| unsignedchar*va = page_address(rx_buffer->page) + 
rx_buffer->page_offset;

8478| unsignedintsize = le16_to_cpu(rx_desc->wb.upper.length);
8479| ecdev_receive(adapter->ecdev, va, size);
8480| adapter->ec_watchdog_jiffies= jiffies;
*+++ **igb_reuse_rx_page**(rx_ring, rx_buffer); *// copied this line 
from igb_main-4.4-ethercat.c -> fix memory leak


8481| }

Adding this line from 4.4 source fixed the leaking for me. (line is 
also missing on 4.14)


Please note that I didn't really study the code besides comparing it 
to 4.4. I do not know if this is safe to do!



Hope this may help
Michael



Best, Jürgen

On 22 Feb 2021, at 8:01, Kivel Niko (PSI) wrote:


Hi Laurent


Did you by any chance also make the 'igb' driver work with 5.4? I 
noticed a memory leak in 3.10 and also in 4.19. I recall there was 
discussion about this year ago, but lost track of it.



best

Niko


--
Paul Scherrer Institute
Dr. Niko Kivel
Forschungsstrasse 111
WBGB/017
5232 Villigen PSI
Switzerland

phone: +41 56 310 2226
email: niko.ki...@psi.ch

From: Etherlab-users  on behalf 
of Karl Zeilhofer 

Sent: Sunday, February 21, 2021 12:02:18 AM
To: etherlab-users@etherlab.org
Subject: Re: [Etherlab-users] [etherlab-users] Compatibility with 
kernel 5.x


Dear Laurent,

did you do any further upgrades?

Do you run the master in kernel or user mode?

What exactly was the cause of the problem?

Kind regards,
Karl

On 6/19/20 2:44 PM, Joye Laurent wrote:

I found and fixed my problem!
It was a kernel configuration failure.

My system is also working fine with a kernel 5.4.

So sorry for this disturbance !!

Regards
Laurent

On Fri, 2020-06-19 at 08:57 +, Joye Laurent wrote:

Hello,

I'm using the Etherlab master with the patches from Gavin Lambert
(changeset 33b922ec1871
http://hg.code.sf.net/p/etherlabmaster/code
)
with a kernel 4.19. It's work like a charm!

I have to upgrade my system
to fix the Y2038 problem. That's why I
need to upgrade to the Linux kernel 5.4.

But Since I boot my system with the kernel 5.4, the EtherCAT master
doesn't found anymore slaves. There are no announced error.

Did anybody already made some experiences with a Linux kernel > 5?

Regards
Laurent
___
etherlab-users mailing list
etherlab-users@etherlab.org

http://lists.etherlab.org/mailman/listinfo/etherlab-users






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



--
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

--
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Complements for a Etherlab Master build system

[Jürgen Walter • DATATRONiQ]

Mike,


I just found and tested a Github project
(https://github.com/icshwi/etherlabmaster) which has very clean build
system for Etherlab master which also includes the patches from Gavin
Lambert.


thanks for sharing - looks really good!

From their README:

This is NOT a web application, NOT an Apps for phones, NOT a cloud 
application.


:)

Thanks, Jürgen


On 9 Jan 2020, at 10:39, Mike O'Connor wrote:


Hi All

I just found and tested a Github project
(https://github.com/icshwi/etherlabmaster) which has very clean build
system for Etherlab master which also includes the patches from Gavin
Lambert.

The really nice feature is the direct support of DKMS and most of the
systemd setup needed also.

It did miss one feature, it did not set the network interface up, so
that has to be done via netplan or ifupdown.

My thanks to the developer Timo Korhonen and the team at ESS EPICS : 
e3


Cheers

Mike

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

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

Re: [etherlab-users] AL status message 0x0036: "DC Sync0 Cycle Time"

[Jürgen Walter • DATATRONiQ]

Hi Mike,


I'm attaching the makefile I used. It's the makefile provided by 
synapticon: ...

cool - many thanks; this will certainly be helpful!!



Can you answer to any of my questions? :)


I wanted to thank you all for your valuable advice. Now I'm acheiving 
near 3.5 kHz loop rate without a single datagram loss. My configured 
system is (just for reference): Ubuntu 16.04 with kernel 
4.8.15-rt10(preempt_rt patched) and support for native driver. I 
would like to ask another question: In the dc_user example I don't 
understand why the latency is measured that way. Could someone make 
it more clear? This latency is the latency of our application (the 
time the scheduler does to put our process to running, so that our 
application can process the newly arrived datagram)? What quantity is 
measured exactly with this latency? Bonus: Can we measure the time 
the datagram does to leave and come back to the master, with 
wireshark accurately?


I would love to  -however, only a user myself and not really deep into 
the protocol stack (never even tried debugging the datagrams on the wire 
(debug interface, Wireshark (but I want to!))


I will also share -once I get it all working to good satisfaction also 
share my setup/steps to epiphany. fyi- I am not sure if it is really 
worth doing the entire Xenomai dance - shouldn't latency (on a modern 
and fast enough system (such as your laptop)) mostly be determined by 
the quality of the ethernet driver and of course the chipset? Just 
saying this, because I think the "preempt" seems pretty much standard 
and is really simple to patch and compile.


Thanks!! Jürgen

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

Re: [etherlab-users] AL status message 0x0036: "DC Sync0 Cycle Time"

[Jürgen Walter • DATATRONiQ]

Hi Mike,

glad to hear you got it working. Can you please clarify:

I wanted to thank you all for your valuable advice. Now I'm acheiving 
near 3.5 kHz loop rate without a single datagram loss. My configured 
system is

are you still trying to go for 5-10kHz (as per your initial e-mail)?


Ubuntu 16.04 with kernel 4.8.15-rt10 (preempt_rt patched)
did you compile this yourself or did you find a low latency / preempt 
version in the Ubuntu repos?



and support for native driver.

what do you mean by "native driver" - is this the generic driver?

Finally, do you mind writing a short list of commands (while the memory 
is still fresh ;) ) for us and for your future self, perhaps:


1. built the custom kernel 4.8.x for preempt_rt
2. built etherlab, ie `./configure --options `

Thank you! Jürgen


On 2 Apr 2018, at 18:19, Mike Karam wrote:


Hi all,

I wanted to thank you all for your valuable advice. Now I'm acheiving 
near 3.5 kHz loop rate without a single datagram loss. My configured 
system is (just for reference): Ubuntu 16.04 with kernel 
4.8.15-rt10(preempt_rt patched) and support for native driver. I would 
like to ask another question: In the dc_user example I don't 
understand why the latency is measured that way. Could someone make it 
more clear? This latency is the latency of our application (the time 
the scheduler does to put our process to running, so that our 
application can process the newly arrived datagram)? What quantity is 
measured exactly with this latency? Bonus: Can we measure the time the 
datagram does to leave and come back to  the master, with wireshark 
accurately?


Thank you in advance,
Mike Karam

Στις Πέμ, 8 Μαρ 2018, 5:37 μ.μ. ο χρήστης Mike 
Karam <mike9...@hotmail.com<mailto:mike9...@hotmail.com>> 
έγραψε:

Hi Martin,

thanks for the advice. It seems to me that the hard real time 
RT-Preempt patch
cannot be avoided if I want to achieve my goal. I will keep that in 
mind and probably

come back to that.

Thanks again,
Mike



Από: Mike Karam <mike9...@hotmail.com<mailto:mike9...@hotmail.com>>
Στάλθηκε: Πέμπτη, 8 Μαρτίου 2018 5:09 μμ
Προς: Jürgen Walter • DATATRONiQ
Κοιν.: 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Θέμα: Απ: [etherlab-users] AL status message 0x0036: "DC Sync0 
Cycle Time"


Hi Jurgen,

thanks for your reply. I forgot to mention that I'm running the 
lowlatency package of kernel 4.8.0-58. The thing is that,
the team wants 16.04 Ubuntu because of the ROS Kinetic development, so 
I don't think I can use
a 3.x kernel (although last time I checked there is also a 4.x 
PREEMPT_RT patch also). I didn't think that
soft-real time vs hard-real time makes such a difference. I will try 
and come back on that.
Another observation of mine is that using Wireshark, the time the 
datagrams left and the time the datagrams came couldn't
get less than 240 μs. Shouldn't the DC use of the master, change this 
time difference  to something very small (e.g 100,50,20 μs),

till there is synchronization loss or packet loss?

Thanks again,
Mike

____________
Από: Jürgen Walter • DATATRONiQ 
<j...@datatroniq.com<mailto:j...@datatroniq.com>>

Στάλθηκε: Πέμπτη, 8 Μαρτίου 2018 4:21 μμ
Προς: Mike Karam
Κοιν.: 
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Θέμα: Re: [etherlab-users] AL status message 0x0036: "DC Sync0 
Cycle Time"


Hi Mike,

I was in a similar boat like you just not too long ago. So, first 
thing,
you need to get your Linux system "real-time" --> best to use 
PREMPT_RT

in the vanilla Kernel.

That said, for using DC and > 1kHz I never got the "generic" driver to
work. How about you downgrade to a 3.x kernel, e.g. 3.18 and use one 
of
the supported drivers w/ patches for RT operation. That is what I did 
-

I also bought a network interface card with a supported chipset and
installed that into a PCIe slot.

Since then, I am pretty much a happy camper.

I hope this helps. Jürgen

On 8 Mar 2018, at 14:23, Mike Karam wrote:


Hi,

I'm trying to create an EtherCAT communication with an XMC4800, using
IgH EtherCAT. I'm using 16.04 Ubuntu with 4.8.0-58 kernel. I
downloaded the code from sourceforge and run the code (a bit 
modified,

see attachment) found in examples/dc_user. If I use a loop frequency
of 1 KHz all things go well (despite some datagrams UNMATCHED
warnings). But if I increase the loop rate to 5 or 10 KHz I'm seeing
the error in the subject. My goal is at least 10Khz succesful 
(withoul

losses) communication. Below is the output I'm getting in the kernel
log:


Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel:
[13658.296909] EtherCAT: Requesting master 0...
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel:
[13658.296912] EtherCAT: Successfully requested master 0.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel:
[13658.29

Re: [etherlab-users] AL status message 0x0036: "DC Sync0 Cycle Time"

[Jürgen Walter • DATATRONiQ]

Hi Mike,

thanks for your reply. I forgot to mention that I'm running the 
lowlatency package of kernel 4.8.0-58. The thing is that,
the team wants 16.04 Ubuntu because of the ROS Kinetic development, so 
I don't think I can use
a 3.x kernel (although last time I checked there is also a 4.x 
PREEMPT_RT patch also).
I thought that, too - however, it is no problem at all to compile your 
own 3.18 kernel on Ubuntu 16.04 and just install it - that is what we 
are currently running.


since Martin mentioned that he is using a generic driver, I guess that 
is OK - however, notice his hardware is probably also a high-quality, 
dedicated NIC via PCIe (e1000e) - the hardware of the ethernet 
device/NIC makes a big difference!



Jürgen
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] AL status message 0x0036: "DC Sync0 Cycle Time"

[Jürgen Walter • DATATRONiQ]

Hi Mike,

I was in a similar boat like you just not too long ago. So, first thing, 
you need to get your Linux system "real-time" --> best to use PREMPT_RT 
in the vanilla Kernel.


That said, for using DC and > 1kHz I never got the "generic" driver to 
work. How about you downgrade to a 3.x kernel, e.g. 3.18 and use one of 
the supported drivers w/ patches for RT operation. That is what I did - 
I also bought a network interface card with a supported chipset and 
installed that into a PCIe slot.


Since then, I am pretty much a happy camper.

I hope this helps. Jürgen

On 8 Mar 2018, at 14:23, Mike Karam wrote:


Hi,

I'm trying to create an EtherCAT communication with an XMC4800, using 
IgH EtherCAT. I'm using 16.04 Ubuntu with 4.8.0-58 kernel. I 
downloaded the code from sourceforge and run the code (a bit modified, 
see attachment) found in examples/dc_user. If I use a loop frequency 
of 1 KHz all things go well (despite some datagrams UNMATCHED 
warnings). But if I increase the loop rate to 5 or 10 KHz I'm seeing 
the error in the subject. My goal is at least 10Khz succesful (withoul 
losses) communication. Below is the output I'm getting in the kernel 
log:



Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296909] EtherCAT: Requesting master 0...
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296912] EtherCAT: Successfully requested master 0.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296961] EtherCAT 0: Domain0: Logical address 0x, 18 
byte, expected working counter 3.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296962] EtherCAT 0:   Datagram domain0-0-main: Logical offset 
0x, 18 byte, type LRW at 91a5b5c9d858.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296981] EtherCAT 0: Master thread exited.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.296983] EtherCAT 0: Starting EtherCAT-OP thread.
Mar  8 14:42:31 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13658.297040] EtherCAT WARNING 0: 15 datagrams UNMATCHED!
Mar  8 14:42:32 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13659.296406] EtherCAT WARNING 0: 13437 datagrams UNMATCHED!
Mar  8 14:42:32 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13659.297430] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 6725 times.
Mar  8 14:42:33 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13660.296475] EtherCAT WARNING 0: 13455 datagrams UNMATCHED!
Mar  8 14:42:33 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13660.298486] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 6734 times.
Mar  8 14:42:34 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13661.296543] EtherCAT WARNING 0: 13442 datagrams UNMATCHED!
Mar  8 14:42:34 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13661.299562] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 6726 times.
Mar  8 14:42:35 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13662.296611] EtherCAT WARNING 0: 13388 datagrams UNMATCHED!
Mar  8 14:42:35 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13662.300630] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 6700 times.
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.296679] EtherCAT WARNING 0: 13414 datagrams UNMATCHED!
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.301699] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 6715 times.
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.310699] EtherCAT WARNING 0-0: Slave did not sync after 5000 ms.
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.312411] EtherCAT ERROR 0-0: Failed to set SAFEOP state, slave 
refused state change (PREOP + ERROR).
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.312949] EtherCAT ERROR 0-0: AL status message 0x0036: "DC Sync0 
Cycle Time".
Mar  8 14:42:36 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13663.313501] EtherCAT 0-0: Acknowledged state PREOP.
Mar  8 14:42:37 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13664.296893] EtherCAT WARNING 0: 14550 datagrams UNMATCHED!
Mar  8 14:42:37 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13664.302791] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 7285 times.
Mar  8 14:42:38 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13665.296872] EtherCAT WARNING 0: 14323 datagrams UNMATCHED!
Mar  8 14:42:38 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13665.303849] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 7165 times.
Mar  8 14:42:39 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13666.296910] EtherCAT WARNING 0: 14357 datagrams UNMATCHED!
Mar  8 14:42:39 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13666.304931] EtherCAT WARNING: Datagram 91a5b5c9d858 
(domain0-0-main) was SKIPPED 7184 times.
Mar  8 14:42:40 mikekaram-HP-EliteBook-Folio-9470m kernel: 
[13667.296989] 

Re: [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 
 
 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
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

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

[Jürgen Walter • DATATRONiQ]

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) 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 :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, 20, 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