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

[Jeff Krasky]

> 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.

I believe this is why it is up to the person writing the code to decide
this.  If you know your algorithm takes 800 microseconds to run, then don't
pick a cycle time of 500 microseconds.  If your algorithm is taking 800
microseconds to run, pick a cycle time of 1 millisecond.

It seems like there is a difference of thought on what type of protocol
EtherCAT is.  Maybe someone can correct me, but I have been thinking of
EtherCAT as an isochronous protocol.  To me, that means you pick a cycle
time, say 1 millisecond, and then your code gets an interrupt every
millisecond.  Upon detecting the interrupt, you read in new data,
process/calculate, and send out new data.  Then you just wait for the next
interrupt.

It sounds like what some people are describing here is the desire for a
non-cyclic protocol.  If that is the case, one question comes to mind: will
all the nodes send data to the Master at EXACTLY the same time?  Lets say
you modify EtherCAT to deliver an interrupt to your program when new data
arrives on the network card (so you can process the new data as soon as
possible).  Well, if you have 30 nodes, you can expect 30 interrupts
probably.  So you detect one node's new data, go fetch it, and most likely
before you even get done processing it, some other node will send something?
How many times can your program be interrupted?  Are you going to have a
stack of nested interrupts?  Even if you design the code to allow for all of
these interrupts, most likely you won't finish processing data for any node
until you have received all node's data, right?  Like this:

<wait for Ethernet card to have one node's data>
start processing for one node
get interrupted for more data
do a little more processing
get interrupted again
...
...
...
get interrupted for the last node's data
finish processing
send

And if this somehow worked, like the nodes had VERY different timing
requirements, then you wouldn't be operating synchronously.  And isn't the
idea of using EtherCAT to be synchronous?

I think the advantage of just waiting until your cycle time has elapsed is
that you can go get the data from all nodes at once.