[etherlab-users] Knowing when the packet has finished

[Yan Prochazka]

Hello Richard and others,

did anybody tried how low one can get with the sleep times in example 
below without crashing server?
We are going (not there yet) to try to close motion control servo loop 
over EtherCAT and ideally would like to see something like 1us 
(microseconds) for the first delay and 250us for the second. Would you 
consider that achievable (in case of less than 10 EtherCAT nodes) ?

Thanks and best regards to all,
Yan Prochazka

On 10/25/2011 03:44, Richard Hacker wrote:
> OK here is a solution to your problem without changing EtherCAT
>
> put all your input slaves into one domain and all your output domains in
> another. Then
>
> while (true) {
> 	ecrt_domain_queue(input_domain);
> 	ecrt_master_send();
> 	sleep(1ms);
> 	ecrt_master_receive();
> 	ecrt_domain_process(input_domain);
> 	ecrt_domain_process(output_domain);
> 	calculate();
> 	ecrt_domain_queue(output_domain);
> 	ecrt_master_send();
> 	sleep(39ms);
> }
>
>
>> Finally, I would end the conversation if your reason for arguing is just
>> because "you don't really want to change the code", either because "you
>> don't get paid for it" or "you don't want to get back to old code" or "you
>> are too lazy" and we'd try to modify the drivers ourselves.
> None of the above, except that time is a continuous deficiency on our side.
>
> The issue is that cyclic tasks by nature are timer driven tasks, not interrupt
> driven. These two models mix as good as oil and water. The master does not
> react on network card interrupts.
>
> If the input_domain has not come back by the time ecrt_master_receive() is
> called, the master *will* puke and there is no way from stopping him from
> doing so. That is by definition so, not by policy.
>
> On the other hand, EtherCAT code is LGPL. You are free to modify the master in
> terms of the Licence. That means that you are not allowed to break the
> ethercat portion of the code in terms of the Beckhoff License (NOTE: NO new
> thread on this point), but if you wish to change the master's response to
> missing frames and ignore it if the master recons that the frame might not
> have had the chance to be back by the time master_receive() is called, then
> sleep a little longer or whatever, you can do it yourself.
>
>
> Mit freundlichem Gruß
>
> Richard Hacker
>