Hallo BigNose,<br><br>I've just read the documentation of igh ethercat master, especially the chapter <b>4.2 Native EtherCAT Device Drivers</b>.<br>It says, there is no need to have an interrupt, because the "communication is highly deterministic: A<br>

frame is sent and will be received again after a constant time" in the same network. Bad that I didn't read it before.<br>So now I think, what we need to do, is to find out that constant time for our specific network by trial and error.<br>

<br>Best regards,<br><br>Jun<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br>

From: +BigNose  <<a href="mailto:bignose@bluewin.ch">bignose@bluewin.ch</a>><br>To: etherlab-users <<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a>><br>Cc: <br>Date: Wed, 14 Dec 2011 10:05:13 +0100<br>

Subject: Re: [etherlab-users] Knowing when the packet has finished cycle<br>Hallo Shahbaz,<br>
<br>
I encountered the exact same problem. So I'm happy, this topic get's<br>
discussed.<br>
<br>
The problem is, that in a realtime control application, it is common,<br>
that you wanna have the sensor values as fresh as possible. And as<br>
Ethercat is very fast, this yields a good starting point.<br>
<br>
But just like you, I also encountered the problem, of how can you get<br>
ASAP the data from the master.<br>
<br>
IMHO the main problem here is, that the interrupt capability of the<br>
driver has been dropped. So that now it has to be polled.<br>
<br>
BTW: Why exactly has the interrupt capability been dropped? What is<br>
the advantage of this?<br></blockquote><div><br>"The interrupt-less operation is desirable, because hardware interrupts are not con-<br>ducive in improving the driver’s realtime behaviour: Their indeterministic incidences<br>

contribute to increasing the jitter. Besides, if a realtime extension (like RTAI) is used,<br>some additional effort would have to be made to prioritize interrupts." - chapter 4.2 <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


To always poll, if the master has received, is IMHO a bit ressource<br>
hungry, and as you said, I wouldn't know how to implement this<br>
anyway, as you push the Master into an error, if you do it.<br>
A maybe workable solution would be, as you said, if one can surely<br>
determine, after how much time, one can surely 100% read the master.<br>
<br>
So I'm really very interested in this topic.<br>
<br>
Thank you<br>
<br>
</blockquote></div>