Hi thanks Jeff for trying to shed some light on the matter from another perspective.
I have to correct a certain point though: A slave does not send its data to the master. The master sends an ethercat packet where the slaves put in their data. This packet is queued automatically in ecrt_domain_queue() together with the output packet. That is what makes EtherCAT soooo efficient. Jeff, you may stop reading here ;). Others who are still not convinced, read on. You must think of EtherCAT like a postal system. In the morning, you go to your inbox and pick up the post for the day. You go to your desk, open the mail, process the stuff, write responses. At the end of the day you take all your outgoing mail to the mailman, then your work for the day is finished - you go home, have some rest, recover, have a beer, watch TV, sleep. In the meantime, the postman is quite busy delivering all your letters, and at the same time also collects new letters for you that he drops in your inbox, sometime during the night. Next day, everything starts from the beginning again. The other EtherCAT option as requested by the initiators of this thread is: In the morning, you run to the postman, scream at him so that he *immediately* thrashes his horse, that he goes out at full speed fetching all the mail for you ASAP and delivers the letters to your inbox. While the postman is running around like a headless chicken, you go and have a cup of coffee and check every 5 seconds whether new mail has arrived (note that the postman does not ring when he delivers mail). Sometime during the morning with 2 hours delay (mind you, you have been checking every 5 seconds because you were very eager in getting the latest news), you eventually see that there is new mail. Now you have the chance to react to the letters you receive. Late in the afternoon, with 2 hours delay (because the postman was still toooooo slow in the morning), your letters are ready for delivery. Then you run to the mailman, scream at him to *immediately* thrash his horse so that he delivers your responses ASAP. You go home, after a short night, everything starts from the beginning again. To save you from checking every 5 seconds for new mail in the morning, you install a bell and request the mailman to ring when he drops new mail, so that you have a more peaceful cup of coffee at least. However, you are still late by 2 hours and your boss fires you for not getting finished in time. Now I ask with tears in my eyes, which system is better??? Another side note: the senders of your letters had their mail for you ready in time for their beer in the evening and they certainly will not get up in the middle of the night to read your letters. They are a relaxed bunch, preferring the first system. Hence your haste, little sleep and the poor old breathless postman were all not worth their while, shame! The bell you installed also did not have the intended effect, you are still fired. I hope that I have now explained EtherCAT in such simple terms that everyone understands what happens when: ecrt_master_receive(): go to the inbox to fetch new mail in the morning ecrt_domain_process(): mail gets distributed to the collegues compute(): work work work ecrt_domain_queue(): the collegues bring the mail to you ecrt_master_send(): you go to the postman with new letters in the afternoon sleep(): Have a beer Note that not all collegues work every day. Some come every 2 days, others once a week, etc. Also, some of the processing takes more than 1 day, maybe 2, maybe 3 days. It really is not helpful that some collegues have 21 hour days, others have 17 hour days, they really do not fit into our schedule of a 24 hour day (analogy why 30ms and 40ms tasks do not work together nicely) The other system: read inputs; calculate; write outputs; sleep will require a mailing system where *all* the senders of letters to you personally deliver their letters directly to your inbox. You personally go and deliver your responses directly to the receivers. There is no postman involved. This system also works, but only for a small environments. It is fast but uses lots of resources. THIS IS NOT ETHERCAT! This is directly attached IO. If that is what you want, then don't use EtherCAT. Our ethercat system works like the first system. It does not *need* a bell (the interrupt), that is why it does not *have* a bell (data_is_there()). The postman is reliable, the mail is *allways* there in the morning. If the mail is not there, the postman is dead and you need a new postman! Having redundent postmen is a completely new aspect. - Richard On Wednesday 19 October 2011 20:26:55 Jeff Krasky wrote: > > 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 > Mit freundlichem Gruß Richard Hacker -- ------------------------------------------------------------------------ Richard Hacker M.Sc. richard.hac...@igh-essen.com Tel.: +49 201 / 36014-16 Ingenieurgemeinschaft IgH Gesellschaft für Ingenieurleistungen mbH Heinz-Bäcker-Str. 34 D-45356 Essen Amtsgericht Essen HRB 11500 USt-Id.-Nr.: DE 174 626 722 Geschäftsführung: - Dr.-Ing. S. Rotthäuser, - Dr.-Ing. T. Finke, - Dr.-Ing. W. Hagemeister Tel.: +49 201 / 360-14-0 http://www.igh-essen.com ------------------------------------------------------------------------ _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
