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

[Jun Yuan]

Hello Shahbaz,

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

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 *if
(answer_is_there)*, 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:
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.
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.

On Tue, Dec 13, 2011 at 3:34 PM, Shahbaz Yousefi <shabbyx at gmail.com> wrote:

> 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


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


> 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)*
>

You're right. I delete this line now :D  I would make sure that
*ecrt_master_receive
*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 *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)
>

Right, we must make sure that we don't receive too soon.


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


Exactly

How would you know this time? That is our question.
>

Trial and error, looking for the worst case.

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

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.


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

Great, so you've got an empirical formula of your own. 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
*EC_BYTE_TRANSMISSION_TIME_NS *to 90 ns or higher in your EtherLab too, I
think that would speed up your transition time from PREOP to OP.


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

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.

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 ;)

Best Regards,
Jun YUAN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111214/dbf26d01/attachment-0004.htm>