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

[Yan Prochazka]

With all the respect and big thanks for EtherLAB (!!!), I still can see 
a big advantage to be able to fetch received data from Ethernet card as 
soon as they are ready. I think I understand described data exchange 
procedure and see the problem with the "wait". We do have a complicated 
control algorithm that take time, so we would like to start calculation 
asap, in order to be done with calculation when time to send the data to 
the slaves ("exchange io" below) come again.
 From the response below:

 > The important thing to note, is that the ethercat frames must be 
waiting on
 > the ethernet card before the master is requested to fetch them, 
otherwise the
 > master will puke and think the frame was lost. Thus fetching data too 
early
 > before the frame has arrived will get you into trouble. That is why 
it is VERY
 > IMPORTANT to sleep after "exchange io".

The question is "How long should the code Sleep ?!?" If it is too short, 
the code would have trouble as mentioned above, if it is too long, there 
will be not enough time to do following calculation.
The easiest thing that might help at least somehow would be to "patch" 
the master code so it would not fret if somebody ask for the data when 
the data are not ready yet, but politely respond with "no new data". 
Then the caller would have a chance to wait a little bit and ask again. 
It might work but it would or insert unnecessary delay or put a lot of 
burden to the system. Much better solution would be to use some kind of 
semaphore/critical section/whatever_is_common_on_Linux with timeout 
where the read request would block and only continue when new data are 
ready to be read.

Then our cycle could look like:

/*be called by timer IRQ*/
exchange io;
ecrt_master_receive_BLOCK() <- that call blocks and return when fetched 
data
									are available
calculate;
/*end*/
/*be called by timer IRQ*/
exchange io;
ecrt_master_receive_BLOCK() <- that call blocks and return when fetched 
data
									are available
calculate;
/*end*/

etc., etc.

It is hard to believe that EtherCAT master really does have no provision 
to get information when received data are ready to be fetched.
Suggestion was posted to use DC. May I ask how the cycle described below 
would look with DC use ?

Thanks and best regards to all,
Jan


On 10/19/2011 07:18, Richard Hacker wrote:
> Hello,
>
> Please let me put things straight: there is no way of knowing when an EtherCAT
> packet has arrived, because there is *NO need to*!!!!
>
> Digital computer controlled systems are sampled data systems with one inherent
> delay cycle from input to output. They are not analog computers. In the limit
> when the cycle time tends to zero they start to *look like* analog computers.
> Where this limit is depends on your application!
>
> So, normal controllers running EtherCAT do:
> calculate;
> exchange io;
> wait;
> calculate
> exchange io;
> wait;
> ... till the end of time
>
> Inside "exchange io", data from the calculation is output to the slaves and AT
> THE SAME TIME the input slaves are sampled (ecrt_master_send() ). These inputs
> wait until the next calculation step before they get processed.
>
> Inside calculate, ethercat data frames are fetched from the ethernet card
> (ecrt_master_receive() ), processed for inputs (which were fetched while the
> program was sleeping) (ecrt_domain_process() ), running your control
> algorithm, and queuing the outputs from your controller (ecrt_domain_queue()
> ). The important thing to note, is that the ethercat frames must be waiting on
> the ethernet card before the master is requested to fetch them, otherwise the
> master will puke and think the frame was lost. Thus fetching data too early
> before the frame has arrived will get you into trouble. That is why it is VERY
> IMPORTANT to sleep after "exchange io".
>
> If this concept does not suit your timing requirements, then EtherCAT is not
> your solution - you need directly attached IO where you can synchronously
> sample inputs, calculate and write outputs. Just before giving up on EtherCAT,
> it has been tested at rates to 10kHz ;)
>
> Oh by the way, we and many others have been working successfully with EtherCAT
> on a number of not so small applications for a few years without needing
> synchronous IO.
>
> - Richard
>
> On Wednesday 19 October 2011 10:52:03 Jordi Blanch Carles wrote:
>> In our case, the whole EtherCat loop would be:
>>
>> ask_for_inputs()<----- ecrt_domain_queue + ecrt_master_send
>> wait_for_packet_received()
>> process_inputs()<----- ecrt_master_receive + ecrt_domain_process
>>
>> make_calculations()
>>
>> send_outputs()<----- ecrt_domain_queue + ecrt_master_send
>>
>> wait_for_next_period()
>>
>
> Mit freundlichem Gruß
>
> Richard Hacker
>