Hello Shahbaz,<br><br>Could you tell me how small the delay has to be in your application then? You said it takes about 5 ms to gather data, so if I set the master cycle at 6ms, for sure I won't get errors from the ecrt_master_receive, will I? Then you've already reduced your delay from 40 ms to 6ms. And you still wants more? You're greedy :D<br>







<br>It's interesting to see that the EtherLab Master doesn't limit your thought. You think it differently. But first, let's discuss about my last version further, in the framework of EtherLab. I made a mistake in <b>if (answer_is_there)</b>, as I don't actually need it, see the reason bellow. So my master runs with a 6ms constant cycle time. And there are two ways to speed it up further:<br>





1) As I wrote in my last email, try to not let that "all domain requiring data" happens. For example, you can limit the number of the domains in the sending list. If there is more domains needs update, put them in a waiting list first, and send those domain request in the next cycle. Or, maybe better, schedule your domain request, let them happens one after another.<br>





2) Reduce your network. You've talked about redundancy. It would be safer to splitt your sensors into two EtherCAT buses with two EtherCAT master. Having 100 slaves on a single EtherCAT bus would means if one of them goes down, the whole bus doesn't work anymore.<br>





<br><div class="gmail_quote">On Tue, Dec 13, 2011 at 3:34 PM, Shahbaz Yousefi <span dir="ltr"><<a href="mailto:shabbyx@gmail.com" target="_blank">shabbyx@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jun,<br><br>Thanks for not giving up on this matter. You got it all right, and your suggested solution is more or less what we had come with also. There is no necessity in splitting the PDOs in multiple domains and indeed EtherCAT</blockquote>







<div><br>You don't need to gather all the pdos at once in each cycle, right? As Emanuele said to me, "It is a waste of band width." Therefore I would splitt it into different domains, and gather data<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">

 proves to be fast enough to handle them. The problem, which was our original question, is <b>How do you implement this line:<br>
<br>    if (answer_is_there)</b><br></blockquote><div> </div><div>You're right. I delete this line now :D  I would make sure that <b>ecrt_master_receive </b>never comes too soon though, in your case, using 6 ms as master cycle would be fine. So I don't actually need to check <b>if (answer_is_there).</b><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"><br>(Note: I would like to remind you that as of the current version, if you <b>ecrt_master_receive</b> too soon, the master decides that something has gone horribly wrong, output some log and threat the situation as an error. So in your algorithm, if none of the answers <i>are there</i> (that is, you received too soon), then the master decides it's an error)<br>







</blockquote><div> <br>Right, we must make sure that we don't receive too soon.<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">
<br>Emanuele can give you more precise numbers if you were interested, but for our case, it would take EtherCAT about 5ms to gather data from all those PDOs. Now, the thing is, with the EtherCAT master, there comes no facility that implements the aforementioned <b>if</b>. So the only way to realize it, would be to<b> make sure enough time has passed since the packet asking for data of this domain was sent.</b></blockquote>







<div> </div><div>Exactly<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">How would you know this time? That is our question.<br></blockquote>







<div> <br>Trial and error, looking for the worst case.<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">
I saw in <b>master.c</b>, in <b>ec_master_idle_thread</b>, an amount of <b>sent_bytes*EC_BYTE_TRANSMISSION_TIME_NS</b> sleep. This suggests that we could follow the same formula and guess our delay. We are however not sure if that is a really well-tested always-correct formula, or just something that has worked for you and has been found by trial and error.<br>







</blockquote><div><br>I'm not among the developers of Etherlab. After the sending out by the master, the datagram needs to go though all the slaves on the bus, forth and back. So if such a formula exists, it has to take account of those things like the number of slaves, the EtherCAT datagram processing time on each slaves, or even cable length etc. Well, it could be complicated, and none of these parameters are constant for different applications.<br>






 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Emanuele has done some latency calculations and have indeed come to the conclusion that, all considered, the better estimate is indeed higher (I'm not sure, but say by around 10%).<br>






</blockquote><div><br>Great, so you've got an <span>empirical formula of your own.</span> It's reasonable for you to have a higher value, because your network is bigger. As I said, this value cannot be constant for different application. If it works for your case, take it in your application. And I recommend you to change this macro <b>EC_BYTE_TRANSMISSION_TIME_NS </b>to 90 ns or higher in your EtherLab too, I think that would speed up your transition time from PREOP to OP. 
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A better way to do it, although I am not sure of the complexities of its implementation, would be for the EtherCAT master to keep a flag for each domain that indicates whether the last packet that has been sent (containing this domain) has arrived yet or not. That is of course, updated after a call to <b>ecrt_master_receive</b>.<br>








<br>So in the end the code would look something like this:<br><br>while (1)<br>{<br>    ecrt_domain_queue(domain);<br>    ecrt_master_send(master);<br><br>    sleep(a lower bound);<br>    ecrt_master_receive(master);<br>







    while (!domain-><b>has_returned</b>)<br>
    {<br>        sleep(a little);<br>        ecrt_master_receive(master);   // try receiving again<br>    }<br><br>    ecrt_domain_process(domain);<br><br>    // process the data<br>    wait_period();<br>}<br><br>Do you think you could implement such a thing? If so, we would most certainly appreciate this feature. We will even send you a delicious chocolate cake as a thank you.<br>





</blockquote><div> <br>Thanks for the attempting cake offer. But I've got my things to do. And I agree with Richard at this point. There are alternatives to reduce your delay within the framework of EtherLab. Why bother change the EtherLab? And personally, I don't like the repeating polling, it would be better to have interrupt when datagram arrives, but that's against the basic idea of EtherLab. <br>

<br>If you like the polling so much that you want to implement this feature yourself, well, I've had a look at the source code, I think theoretically it would work, and it seems that the effort is not that huge. So good luck! And tell me how it goes ;)<br>

<br>Best Regards,<br>Jun YUAN<br></div>

</div>