[etherlab-users] waiting for received frames

[Ian Prochazka]

Exactly!!! Thank you Shahbaz for great summary and reiteration.

And even more useful than function ecrt_domain_received() that would 
need to be polled, seems to me or ecrt_master_receive() that would block 
and wait till data are available or any kind of asynchronous 
notification "data are available"

Best to all, Ian

On 11/21/2013 11:23, Shahbaz Youssefi wrote:
> 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.html
> which 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 for
> our 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 <mailto: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 <mailto:etherlab-users at etherlab.org>
>     http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
>