[etherlab-users] Knowing when the packet has finished cycle
Emanuele Baglini
Emanuele at be-ahead.it
Fri Oct 14 18:36:14 CEST 2011
Hi,
I work in the same lab with Shabbaz, and I want to add something.
Our application is not a control application, but it is a data acquisition application.
In a standard control application you have:
_take the input
_calc
_send the output
_wait for next cycle ---> while waiting you receive the input for the next cycle
And it is fine to wait to receive the data while waiting for the next cycle.
Instead, in our application we want only to collect data, so for us is very important to minimize every delay. Our cycle time is about 40ms, so waste an entire cycle is a lot of time. What we need is:
_send input read command
_wait for input to be received
_wait for next cycle
So, is there a way to know when new data is available?
Enclosed there is an image (on top) where I show what happen with the standard "control" application. As you can see there are 40ms from when the data is available in the slave and when it is available in the master.
In the image on the bottom there what we want, to reduce the delay.
Thank you for your help.
E.
-----Original Message-----
From: etherlab-users-bounces at etherlab.org [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Richard Hacker
Sent: Friday, October 14, 2011 10:02 AM
To: etherlab-users at etherlab.org
Cc: Shahbaz Yousefi
Subject: Re: [etherlab-users] Knowing when the packet has finished cycle
Hi,
I am not sure why you want to go through all this trouble. Of coarse, if your calculation is so long that there is no time to exchange IO, you have trouble looming anyway!
So what do you want to do with the data if you receive it in the same cycle instead of waiting till your next call? For me, there is no point of busily waiting till your packet arrives, instead of being relaxed and receiving the packet next cycle.
The normal run of a control program is:
calculate; exchange io; wait; calculate; exchange io; wait; etc.
where exchange io means: write output and get new inputs. Master receive and domain process simply fetches and processes the data that was transmitted with master_send at the end of you pseudo code examples.
Now, exchange io is done in the background by the network card. This means, that you could call exchange io right at the start of your cycle and subsequently calculate. In this case your calculation and exchange io runs in parallel. This is useful when your calculation is long and you have a lot of data to exchange, i.e.
exchange io; calculate; wait; exchange io; calculate wait; etc.
The drawback is that your propagation time from input change to output reaction is 2 cycles, instead of only 1. That is the price to pay if you have lots of data and a long calculation - there is no free lunch!!!
I do not think that you have a problem. Draw your operations on a time line and convince yourself that once you are in in the loop, you have max 1 cycle delay from input to output. If that is too long for you, then ethercat is not your solution. Then you need direct IO like that of microcontrollers and the like.
- Richard
On Thursday 13 October 2011 17:12:46 Shahbaz Yousefi wrote:
> Hi,
>
> I have been working with etherlab recently and got ethercat working up
> and everything is fine.
>
> There is a delay issue however that I'm concerned about. As seen in
> the examples, the way you read from the network is like this (imagine
> you are interested in reading sensor values):
>
> while (running)
> {
> master receive
> domain process
>
> read data
>
> domain queue
> master send
>
> rt wait period
> }
>
> in which case you assume that the task period is long enough to be
> sure that the packet sent in the bottom of the loop has returned when
> the loop starts again and so you can receive the data.
>
> However, I was wondering if it is possible to, instead of taking an
> upper bound of the time, simply check to see whether the data has arrived or not.
> After some research, I got to this code:
>
> while (running)
> {
> domain queue
> master send
>
> do
> {
> sleep a little
>
> master receive
> domain process
>
> ecrt_domain_state(domain, &state);
>
> } while (state.wc_state != EC_WC_COMPLETE && !timeout)
>
> read data
>
> rt wait period
> }
>
> This way, after sending the packet, you would read the data as soon as
> they arrive.
>
> The problem with this was that, besides the fact that early calls to
> master_receive (or domain_process) generated a huge amount of warning
> about working counter changing to 0/1 and back to 1/1 again, the
> kernel started to at some point keep crashing.
>
> I would like to know, how can I detect when the packet has arrived
> without knowing an upper bound about it and wait blindly by that much?
>
> Note: This is most useful for me for this reason:
>
> I may have different threads requesting data from a domain which
> includes different sensors. Each type of sensor produces data at a
> different rate and I would like to read the data at different rates
> to. I don't want to (and I don't think is even possible) to have
> different threads requesting data from the same domain (because they
> may send the packet while the one for the previous thread hasn't yet arrived). So what I want to is this:
>
> ethercat coordinator:
>
> domain_updating = no
>
> send_request_for_domain
> {
> if (domain_updating == no)
> {
> domain_updating = yes
> domain queue
> master send
> }
> // else, do nothing, it is being updated!
> }
>
> receive_from_domain()
> {
> while (ecrt_domain_data_not_yet_received) // this is the function I need
> wait
> domain_updating = no
> // data available
> }
>
> and then, each thread that wants something from the domain would look
> like
> this:
>
> thread:
> send_request_for_domain
> receive_from_domain
> read data
>
> This way, if two threads call send_request_for_domain at the same
> time, only one of them would actually do the
>
> domain queue
> master send
>
> and both of them use the result.
>
> I would appreciate it if you could shed some light on this matter.
> Shahbaz
>
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
------------------------------------------------------------------------
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: standard_timing.png
Type: image/png
Size: 132728 bytes
Desc: standard_timing.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111014/18f09882/attachment-0005.png>
More information about the Etherlab-users
mailing list