[etherlab-users] waiting for received frames

Thu Nov 21 17:23:22 CET 2013

This is going to be repetition of some very old discussion.

First, to answer Jeroen: yes, what holds me from just calling
ecrt_master_receive as a kind of poll is that it doesn't provide me with an
answer to the following question: "Has all the packets of the domain
arrived yet?". The whole point of `ecrt_check_received` is to answer that
question. Indeed, ecrt_master_receive is still needed before every call to
ecrt_check_received because that is the function that takes messages from
the hardware buffer.

About why we need this:

Here's the classical usage of EtherCAT, which is completely ok for control
and static industrial applications:

1. take input
2. process
3. send output (and request next input)
4. wait cycle

Now the delay between when the slave provides data (just after step 3) and
when the program takes it (step 1) is about one cycle. For example: the
slave reads some sensors every 40ms. In the previous cycle, say at time
100, the program sends a cyclic message (at step 3). The message circulates
and arrives back in 1ms (even sooner in smaller networks) (Note: these
values _are_ realistic). So the data is actually available at time 101.
However, the program waits for next cycle, i.e. wakes up at time 140. Then
it reads the data (step 1).

As you can see, since the cycle time is much larger than the ethercat
message's turnaround time, there's a relatively huge delay from when the
data is already available and when the program reads it (39ms in example
above). In case you want to say "reduce the cycle time", your response is
here: http://lists.etherlab.org/pipermail/etherlab-users/2011/001444.htmlwhich
in short would be that there's no point since the slave doesn't
produce data faster than 40ms and also that _there is NO WAY of knowing
what is the fastest you can get_ (more on this below).

What I'm asking for is the following:

1. send request for input
2. wait until input arrives
3. take input
4. process
5. send output
6. wait cycle

In this case, if at time 100 I send the request (step 1), the packet
arrives after 1 ms, so at time 101 I'll take the input (step 3) and go on
with my processing. I.e. my delay is now 1ms.

Did you notice how the sensor reading delay was reduced from "cycle time"
(possibly large) to "ethercat message's turnaround time" (extremely small)?

----------

Another reason is the following. As I have heard time and time again that
the packet turnaround time is unknown and it should be measured by trial
and error (A real WTF, specially since it's used in a *real-time* system):

*--- quote ---No, there is no way to find out whether a packet has arrived.*

*--- /quote ---*

*--- quote ---Hence, you could deduce for yourself, if you call
master_receive() too early, i.e. before the ethernet packet has arrived,
the master would complain that the packet is lost, and rightly so! How
could the master deduce, "Oh, I was called too early, the packet is still
in transit, I should wait a little longer". No it cannot.--- /quote ---*

*--- quote ---Please let me put things straight: there is no way of knowing
when an EtherCAT packet has arrived, because there is *NO need to*!!!! *

*--- /quote ---*

*--- quote ---The answer is still NO. EtherCAT does not know when the
packet has arrived. So it will not be able to report that information to
you!*

*--- /quote ---*

*--- quote ---So now I think, what we need to do, is to find out that
constant time forour specific network by trial and error.*
*--- /quote ---*

Now here's the catch. I'm not designing an industrial plant where there are
a few and fixed number of slaves so I can measure delays with try and
error. I'm part of a project that makes robotic skins. Any client can
attach and detach any amount of skin (even up to 30000 PDOs and 100
slaves). Any fixed amount of waiting for data to arrive is simply wrong!

So besides the fact that you can benefit from `ecrt_domain_received` to
properly understand network delay for configuration of a static plant
(instead of trial and error!!), you would definitely need it for handling
networks that you wouldn't know in advance.

What I don't understand is why there's so much resistance against a
function that doesn't affect anyone who doesn't use it, is already
implemented and tested, and is also requested by many? Just to name but few
(besides myself):

http://lists.etherlab.org/pipermail/etherlab-users/2011/001423.html
http://lists.etherlab.org/pipermail/etherlab-users/2011/001429.html
http://lists.etherlab.org/pipermail/etherlab-users/2011/001525.html
http://lists.etherlab.org/pipermail/etherlab-users/2012/001751.html
http://lists.etherlab.org/pipermail/etherlab-users/2013/002287.html

Shahbaz

On Thu, Nov 21, 2013 at 2:37 PM, Martin Troxler <
martin.troxler at komaxgroup.com> wrote:

> On 21.11.2013 14:06, Jeroen Van den Keybus wrote:
> > I'm just wondering if the need for receipt notification would e.g. arise
> when someone would send an EtherCAT frame A
> > for gathering data and, as soon as that frame returns, do some
> calculations and send a second frame B to apply process
> > outputs, in an attempt to obtain shorter response times ?
> >
> You can't get shorter bus cycle times than the one needed to transfer the
> frame, i.e. ~80ns per byte + Slave
> transmission times (usually a few 100ns per slave)
>
> Regards
> Martin
>
> Note:
>
> This e-mail is for the named person's use only. It may contain
> confidential and/or privileged information. If you have received this
> e-mail in error, please notify the sender immediately and delete the
> material from any system. Any unauthorized copying, disclosure,
> distribution or other use of this information by persons or entities other
> than the intended recipient is prohibited.
>
> Thank You.
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20131121/ddfc397a/attachment-0003.htm>