[etherlab-users] Knowing when the packet has finished cycle

[Shahbaz Yousefi]

Hello Jun,

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 *How do you implement this line:

    if (answer_is_there)*

(Note: I would like to remind you that as of the current version, if you *
ecrt_master_receive* 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 *are there* (that is, you received
too soon), then the master decides it's an error)

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 *if*. 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.

I saw in *master.c*, in *ec_master_idle_thread*, an amount of *
sent_bytes*EC_BYTE_TRANSMISSION_TIME_NS* 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.

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%).

So as you can see, knowing how much to wait is also not trivial. If
you *do*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 *ecrt_master_receive*.

So in the end the code would look something like this:

while (1)
{
    ecrt_domain_queue(domain);
    ecrt_master_send(master);

    sleep(a lower bound);
    ecrt_master_receive(master);
    while (!domain->*has_returned*)
    {
        sleep(a little);
        ecrt_master_receive(master);   // try receiving again
    }

    ecrt_domain_process(domain);

    // process the data
    wait_period();
}

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.

Emanuele can fill you in with more precise numbers if you were interested,
Thank you,
Shahbaz

On Tue, Dec 13, 2011 at 2:32 AM, Jun Yuan <j.yuan at rtleaders.com> wrote:

> Hello Shahbaz, Hello Emanuele,
>
> so there are 30000 pdos, 100 slaves on the bus, WOW. If I understand
> it rightly, those slaves have different updating rates, all the pdos
> were putted into one domain, and the bus cycle was in 40ms only
> because some slaves (sensors) need 37ms to update its data. Having
> those data with a nearly 40ms delay for the processing is
> unacceptable, so we need to improve it.
>
> I've got an idea. I am not sure if it actually works, but this is my
> suggestion:
>
> The first thing I want to point out, is that the bus cycle and the
> slave's internal updating cycle are two different things. The bus
> cycle should not be limited to the slaves' internal cycle. The bus
> cycle is only limited by two things: the processing time in the while
> loop of the EtherCAT, and the datagram transmission time. Please
> correct me if I am wrong.
>
> As the 40ms delay is a concern here, I think we should have the bus
> running faster. Let's say 1ms cycle time, if it allows. So the data
> would only have a max. 1ms delay for processing.
>
> Those pdos would be splitted into different domains, according to
> their updating frequency. There shall be one EtherCAT thread dealing
> only with the bus. And if the data processing may cost more time than
> 1 ms(bus cycle), each domains can have one data processing thread.
>
> There shall be two list, one for those domain to be sent, the other
> one for those domains that have been sent and waits for receiving the
> answer. The while loop of the EtherCAT thread shall be like this:
>
> while(true) {
>   ecrt_master_receive(master_ptr);
>
>   for (each domain in receiving list) {
>     ecrt_domain_process(domain_ptr);
>    if (answer_is_there) {
>        notify_its_data_process_thread();
>        delete_itself_from_receiving_list();
>    }
>   }
>
>  for (each domain in sending list) {
>    ecrt_domain_queue(domain_ptr);
>   add_itself_to_receving_list();
>  }
>
>  ecrt_master_send(master_ptr);
>
>  wait_for_bus_cycle();
> }
>
> The data processing thread while loop:
> while(true) {
>  add_domain_to_sending_list();
>  wait_for_the_answer();
>  data_processing();
>  wait_for_domain_cycle();
> }
>
> The worst case for datagram transmission is that when all the domains
> require data update.  I don't known how long does it take to transmit
> all the 30000 pdos in all that different domains. You'll need to find
> it out for deciding the bus cycle time. And if it too takes too long,
> well, try to not let that "all domain requiring data" happens.
>
> Hope this can help you.
>
>
> Best Regards,
>
> Jun YUAN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111213/881428d5/attachment-0003.htm>