[etherlab-users] Knowing when the packet has finished

Thu Oct 20 15:05:10 CEST 2011

Hi 

Because EtherCAT works like a closed loop (kind of a huge shift
register), you won't receive any data if you don't send it. 
Slaves do not send data, they manipulate the existing bits of the frame
while it passes around. 

If you sleep long enough for the ethernet frame to travel around
(roughly 80ns per byte), the new data is already there when you call
ecrt_master_receive. 

Our cyclic loop works as follows: 
ecrt_master_receive 
ecrt_domain_process 
ecrt_domain_queue 
ecrt_master_send 
calculate 
sleep 

Pros: calculation occurs while frame is being sent 
Cons: calculated data will be sent a step later 

The sleep time is measured and recalculated and adjusted to a given
cycle time relative to a given start time. 

Regards 
Martin 

>>> Shahbaz Yousefi <shabbyx at gmail.com> 20/10/2011 14:41 >>>
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 ( tel:%2B49%20201%20%2F%2036014-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 ( tel:%2B49%20201%20%2F%20360-14-0 )
http://www.igh-essen.com

Besuchen Sie Komax Wire an der Productronica in München
vom 15. bis 18. November 2011 - Halle B3 Stand 325

Visit Komax Wire at Productronica in Munich
from 15 to 18 November 2011 - Hall B3 Stand 325

Note:
This e-mail is for the named person's use only. It may contain confidential and/or privileged information. If you have received this e-mail in error, please notify the sender immediately and delete the material from any system. Any unauthorized copying, disclosure, distribution or other use of this information by persons or entities other than the intended recipient is prohibited.
Thank You.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111020/fce75ed8/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMAGE.jpg
Type: image/jpg
Size: 40613 bytes
Desc: JPEG image
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111020/fce75ed8/attachment-0004.jpg>