Hi Jun,<br><br>There is a fundamental problem here. There is no way to find out the value 5ms! Yes, with our formula, our guesses and some measures, we think it should be 5ms, but we can't be sure. If it were so, then of course, wait 6ms and everything is perfect. Another reason we cannot hardcode a value (if not knowing the value is not enough!!) is that the user of the skin (yes, we are creating a skin) might just add another piece of skin to the network, increasing the delay. So, the delay may increase, skin would fail, no tactile data, and the robot might just crush your hand shaking hands with you.<br>
<br>I did indeed think about extending the master with this feature, but there is one thing holding me back. In fact, I would be happy if you (or Richard) would answer this question. Imagine you have a big domain for which each <b>ecrt_master_send</b> would require splitting its data into different packets. Now, if you, by shear bad luck, do an <b>ecrt_master_receive</b> while only half of the packets have arrived, what happens? I mean, the fact that master thinks something went wrong I can fix in the master code, but would receiving another time after that make everything correct? Or would those half of packets be thrown away and therefore another read would again cause an error?<br>
<br>I'm not sure if I'm being clear so let me go with a simple example. Imagine your domain is big and so each <b>ecrt_master_send</b> needs to send 10 packets. The delay is 2ms. Now exactly 2ms after, you issue an <b>ecrt_master_receive</b>. At this time, 4 packets have arrived, the 5th is being read and 5 others are on the way. If you issue an <b>ecrt_master_receive</b>, the master gives you an error. Fine. Now if you see that error, wait 1ms more so that all the remaining packets arrive, would <b>ecrt_master_receive</b> work correctly?<br>
<br>Regards,<br>Shahbaz<br><br><div class="gmail_quote">On Wed, Dec 14, 2011 at 12:19 PM, Jun Yuan <span dir="ltr"><<a href="mailto:j.yuan@rtleaders.com">j.yuan@rtleaders.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"><div class="im">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><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>
</div></div></blockquote><div><br><br>By the way, it's a waste of bandwidth if the have different cycle times. So if one type of sensor produces data at 1000hz and the other at 100hz, then we do split them in two, but all the 1000hz ones would be in one domain and all the 100hz ones in the other.<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"><div class="gmail_quote"><div> <br>
</div><div class="im"><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><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><div class="im"><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><div> <br>Right, we must make sure that we don't receive too soon.<br><br></div><div class="im"><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><div>Exactly<br><br></div><div class="im"><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><div> <br>Trial and error, looking for the worst case.<br><br></div><div class="im"><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><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><div class="im"><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><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><div class="im"><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></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
{<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><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,<span class="HOEnZb"><font color="#888888"><br>Jun YUAN<br></font></span></div>
</div>
</blockquote></div><br>