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.trox...@komaxgroup.com <mailto:martin.trox...@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@etherlab.org <mailto:etherlab-users@etherlab.org> http://lists.etherlab.org/mailman/listinfo/etherlab-users
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
