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

[Jeff Krasky]

> I see ! My original thought was:
> "wake up, send data, read data, calculate new data to be send, wait for 
> next interrupt"

Ok, if you were to go about it like this, where you send AFTER waking up,
then why was it so important to read so fast?  I mean, in this approach you
are reading & calculating, then waiting.  If you can afford to wait after
reading, isn't that the same as just waiting and then reading?

wake up, send (previous calc data), read, calculate, wake up....

You are waking up and sending what you calculated before you went to sleep.
Now, 


wake up, read, calculate, send, wake up....

This approach sends what it just calculated, which is the freshest possible
data.


> The suggested approach:
> "wake up, read data (from local Ethernet adapter cache), calculate, send
> data, wait" has two issues:
> (1) it is not given when data will be sent out because calculation may 
> take various time. That might be (quite serious) issue for control loop 
> closed over EtherCAT

Your approach has that also.  Your approach of wake up, send data, read
data, calculate new data to be send, wait....Well, if the "calculate new
data to be sent" takes too much time then you won't have time to "wait for
next interrupt" - you will miss the next interrupt, meaning you won't send
until the interrupt after that.  Meaning you missed an entire cycle.  My
approach means the data goes out late.  Neither is acceptable for closing a
loop, but they both have the same problem, not just mine.

> (2) if the calculation is long enough that it goes close to interrupt 
> period, then attempt to read data would still lead to problems because 
> data are not ready yet.

I am not sure what you mean here.  The data to read comes from the slaves,
so something will be there (it will be incorrect if I was late on a cycle
though, but again, both approaches have this problem).

In both (1) and (2) the issue you are referring to, I believe, is what
happens if your calculation is longer than your chosen cycle time.  Like I
mentioned, if your calculation takes 800 microseconds then you have no
choice but to use a cycle time > 800 microseconds.  If your calculation
varies between 750 and 850 microseconds then you have no choice but to use a
cycle time > 850 microseconds.

Step 1: Determine the max length of calculation, worst case
Step 2: Make sure interrupt does not come faster than this