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