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 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><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>
<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 make sure enough time has passed since the packet asking for data of this domain was sent. How would you know this time? That is our question.<br>
<br>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>
<br>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><br>So as you can see, knowing how much to wait is also not trivial. If you <i>do</i> have a good formula for estimation of this time, we would be happy to hear about it. 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>
<br>Emanuele can fill you in with more precise numbers if you were interested,<br>Thank you,<br>Shahbaz<br><br>On Tue, Dec 13, 2011 at 2:32 AM, Jun Yuan <span dir="ltr"><<a href="mailto:j.yuan@rtleaders.com">j.yuan@rtleaders.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Shahbaz, Hello Emanuele,<br>
<br>
so there are 30000 pdos, 100 slaves on the bus, WOW. If I understand<br>
it rightly, those slaves have different updating rates, all the pdos<br>
were putted into one domain, and the bus cycle was in 40ms only<br>
because some slaves (sensors) need 37ms to update its data. Having<br>
those data with a nearly 40ms delay for the processing is<br>
unacceptable, so we need to improve it.<br>
<br>
I've got an idea. I am not sure if it actually works, but this is my suggestion:<br>
<br>
The first thing I want to point out, is that the bus cycle and the<br>
slave's internal updating cycle are two different things. The bus<br>
cycle should not be limited to the slaves' internal cycle. The bus<br>
cycle is only limited by two things: the processing time in the while<br>
loop of the EtherCAT, and the datagram transmission time. Please<br>
correct me if I am wrong.<br>
<br>
As the 40ms delay is a concern here, I think we should have the bus<br>
running faster. Let's say 1ms cycle time, if it allows. So the data<br>
would only have a max. 1ms delay for processing.<br>
<br>
Those pdos would be splitted into different domains, according to<br>
their updating frequency. There shall be one EtherCAT thread dealing<br>
only with the bus. And if the data processing may cost more time than<br>
1 ms(bus cycle), each domains can have one data processing thread.<br>
<br>
There shall be two list, one for those domain to be sent, the other<br>
one for those domains that have been sent and waits for receiving the<br>
answer. The while loop of the EtherCAT thread shall be like this:<br>
<br>
while(true) {<br>
  ecrt_master_receive(master_ptr);<br>
<br>
  for (each domain in receiving list) {<br>
    ecrt_domain_process(domain_ptr);<br>
    if (answer_is_there) {<br>
        notify_its_data_process_thread();<br>
        delete_itself_from_receiving_list();<br>
    }<br>
  }<br>
<br>
 for (each domain in sending list) {<br>
   ecrt_domain_queue(domain_ptr);<br>
   add_itself_to_receving_list();<br>
 }<br>
<br>
 ecrt_master_send(master_ptr);<br>
<br>
  wait_for_bus_cycle();<br>
}<br>
<br>
The data processing thread while loop:<br>
while(true) {<br>
  add_domain_to_sending_list();<br>
  wait_for_the_answer();<br>
  data_processing();<br>
  wait_for_domain_cycle();<br>
}<br>
<br>
The worst case for datagram transmission is that when all the domains<br>
require data update.  I don't known how long does it take to transmit<br>
all the 30000 pdos in all that different domains. You'll need to find<br>
it out for deciding the bus cycle time. And if it too takes too long,<br>
well, try to not let that "all domain requiring data" happens.<br>
<br>
Hope this can help you.<br>
<br>
<br>
Best Regards,<br>
<span class="HOEnZb"><font color="#888888"><br>
Jun YUAN<br>
</font></span></blockquote></div><br>