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