[etherlab-users] Knowing when the packet has finished

Thu Oct 20 14:41:54 CEST 2011

Hi Richard,

I wouldn't have responded in the mailing list per your request of continuing
this outside the mailing list, but I didn't hear back from you and the
conversation seems like it's still continuing here.

The way you describe what we need does sound bad, but what we need is in
fact different. I will use your own analogy.

First of all, let's compute the times better:

- The real-time thread's working cycle is, let's say 40ms. Therefore, a
complete 24-hour day is 40ms
- The time we process the data is 0.5ms. Therefore, the thread only works
0.5/40*24*60 = 18 minutes.
  * Problem is you assume the thread is working from morning to night, while
in fact it only works less than 20 minutes.
- The time it takes for EtherLab's packet to circulate (in our case with 100
slaves) is roughly 3.3ms. That is 3.3/40*24 ~= 2 hours
  * I don't know if you actually computed that or it was a lucky guess, but
yes, it does take the postman 2 hours to go take the mail! :))

Now imagine the postman brings you newspaper everyday. It takes the
newspaper company (slaves) to produce newspaper only once a day and they
produce it at 8 in the morning.

Your method is this:

- You wake up in the morning, take the newspaper that is already there.
- You read it for 20 minutes and you write a summary for the president.
- You tell the postman to go bring you the newspaper of today (because today
you read the newspaper of yesterday)
- You start kicking dirt, drinking coffee, having beer, watching tv and do
nothing. In the meantime, the postman has already brought you today's
newspaper.
  Regardless of the arrival of the new newspaper, you still do nothing.
Finally you go to bed
- Next morning, you wake up again and take the newspaper that is already
there (which is yesterday's newspaper) and all over again

Problem with your method? You are always one day behind. The enemy is moving
in land, taking your city's one by one and you don't tell the president
about it until the next day.

What we are proposing:

- You wake up in the morning.
- You tell the postman to go bring you the newspaper of **today**
- You know it takes the postman roughly 2 hours to go and return, so you go
to sleep again.
- You wake up first after 2 hours, then every half hour to check if the
postman has arrived. Most likely, if he hasn't arrived the first time you
check he will the second time.
- When he arrives, you take the newspaper of today, read it for 20 minutes
and report to the president.
  You have done a great job of notifying the president of the newest threats
and you dedicate the rest of the day to your family. At night you go to
sleep.
- Next morning, you wake up and all over again

Problem with our method? The postman doesn't like ringing bells (no
interrupts for arrival of data). Worse than that, there is a monster out the
window so that if you try looking for the postman it pokes you in the eye
(no polling of data arrival).

Our request? Please remove the monster so we could check to see when the
postman has arrived.

Let me review:

The task's period is much larger than the time it takes the network to send
an receive data (24 hours period compared to 2 hours for postman to go and
come back)
With your method, once you wake up, you get data of 22 hours ago. But you
immediately process them
With our method, once you wake up, you wait for 2 hours, then you process
data of this instant.

Does the first method really look better to you? All that stands between the
second method working or not is a simple "is_there_new_data()"!

Shahbaz

P.S. My colleague had visualized the two scenarios and emailed the list a
few days ago, but apparently it has gone to spam. Is it possible for you to
retrieve it? Or should I send on his behalf?

On Thu, Oct 20, 2011 at 11:28 AM, <etherlab-users-request at etherlab.org>wrote:

>
> Date: Thu, 20 Oct 2011 11:28:05 +0200
> From: Richard Hacker <ha at igh-essen.com>
> Subject: Re: [etherlab-users] Knowing when the packet has finished
>        cycle
> To: etherlab-users at etherlab.org
> Message-ID: <201110201128.05123.ha at igh-essen.com>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111020/bdd4edbc/attachment-0003.htm>