Ok. I can reduce the cycle time. For example make it 10 times faster. This way, since my hardware doesn't have data this fast, I would wake up in period 1, send request and sleep, wake up in period 2, receive and process, sleep all the periods 3 to 10. This is absolutely the same thing I have been saying the whole time. Without waking up in between periods 3 to 10.<br>
<br>You see, the thing is, if you know the packet will arrive after let's say 4ms (regardless of how fast the hardware generates data), then yeah, you can send, sleep 4ms, receive process and wait period. But how do you find that 4ms?<br>
<br>We were thinking of calibrating first, so you try to find that value for your network and then start working, but the thing is, you still have no way of knowing when your data arrived so that you can measure the turnaround time!<br>
<br>What I'm saying is, you tell me to reduce the cycle time, I won't have a problem with that, but how do you know how much to reduce it if you can't measure the turnaround time?<br><br><div class="gmail_quote">
On Thu, Oct 20, 2011 at 3:56 PM,  <span dir="ltr"><<a href="mailto:etherlab-users-request@etherlab.org">etherlab-users-request@etherlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> You get data of last night, issue commands and send the postman at night.<br>
> Delay? 1 day<br>
> Our method, you get the data of today, issue commands and send the postman<br>
> again today (another thread). Delay? As short as it can be. (If you<br>
> remember, that is also something we wanted. Not to be restricted to<br>
> sending the postman only once a day, but as soon as we need him).<br>
<br>
In EtherCAT, I believe this would be accomplished by setting the cycle time<br>
to a shorter value.  If you set it to 1 hour instead of 24, you can get in<br>
24 values of new data in a day, not just one (and the postman will be in<br>
excellent physical condition, ready for Boston Marathon!).  So why not go<br>
from 40ms to something significantly smaller?  If something prohibits you<br>
from going to a smaller cycle time then I would guess you have reached the<br>
limits of EtherCAT.  (Maybe the "post office" isn't good enough for you and<br>
you need a team of dedicated FedEx workers to go out and collect mail when<br>
you order them to.  Certain FedEx workers go out every hour, others every 3<br>
hours, etc., you decide.  If that's the case, I don't think it's the<br>
EtherCAT model.)<br>
<br>

</blockquote></div><br>