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

[Richard Hacker]

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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
> 

Mit freundlichem Gruß

Richard Hacker

-- 
------------------------------------------------------------------------

Richard Hacker M.Sc. 
richard.hacker at 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

------------------------------------------------------------------------