With all the respect and big thanks for EtherLAB (!!!), I still can see
a big advantage to be able to fetch received data from Ethernet card as
soon as they are ready. I think I understand described data exchange
procedure and see the problem with the "wait". We do have a complicated
control algorithm that take time, so we would like to start calculation
asap, in order to be done with calculation when time to send the data to
the slaves ("exchange io" below) come again.
From the response below:
> The important thing to note, is that the ethercat frames must be
waiting on
> the ethernet card before the master is requested to fetch them,
otherwise the
> master will puke and think the frame was lost. Thus fetching data too
early
> before the frame has arrived will get you into trouble. That is why
it is VERY
> IMPORTANT to sleep after "exchange io".
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.
The easiest thing that might help at least somehow would be to "patch"
the master code so it would not fret if somebody ask for the data when
the data are not ready yet, but politely respond with "no new data".
Then the caller would have a chance to wait a little bit and ask again.
It might work but it would or insert unnecessary delay or put a lot of
burden to the system. Much better solution would be to use some kind of
semaphore/critical section/whatever_is_common_on_Linux with timeout
where the read request would block and only continue when new data are
ready to be read.
Then our cycle could look like:
/*be called by timer IRQ*/
exchange io;
ecrt_master_receive_BLOCK() <- that call blocks and return when fetched
data
are
available
calculate;
/*end*/
/*be called by timer IRQ*/
exchange io;
ecrt_master_receive_BLOCK() <- that call blocks and return when fetched
data
are
available
calculate;
/*end*/
etc., etc.
It is hard to believe that EtherCAT master really does have no provision
to get information when received data are ready to be fetched.
Suggestion was posted to use DC. May I ask how the cycle described below
would look with DC use ?
Thanks and best regards to all,
Jan
On 10/19/2011 07:18, Richard Hacker wrote:
Hello,
Please let me put things straight: there is no way of knowing when an EtherCAT
packet has arrived, because there is *NO need to*!!!!
Digital computer controlled systems are sampled data systems with one inherent
delay cycle from input to output. They are not analog computers. In the limit
when the cycle time tends to zero they start to *look like* analog computers.
Where this limit is depends on your application!
So, normal controllers running EtherCAT do:
calculate;
exchange io;
wait;
calculate
exchange io;
wait;
... till the end of time
Inside "exchange io", data from the calculation is output to the slaves and AT
THE SAME TIME the input slaves are sampled (ecrt_master_send() ). These inputs
wait until the next calculation step before they get processed.
Inside calculate, ethercat data frames are fetched from the ethernet card
(ecrt_master_receive() ), processed for inputs (which were fetched while the
program was sleeping) (ecrt_domain_process() ), running your control
algorithm, and queuing the outputs from your controller (ecrt_domain_queue()
). The important thing to note, is that the ethercat frames must be waiting on
the ethernet card before the master is requested to fetch them, otherwise the
master will puke and think the frame was lost. Thus fetching data too early
before the frame has arrived will get you into trouble. That is why it is VERY
IMPORTANT to sleep after "exchange io".
If this concept does not suit your timing requirements, then EtherCAT is not
your solution - you need directly attached IO where you can synchronously
sample inputs, calculate and write outputs. Just before giving up on EtherCAT,
it has been tested at rates to 10kHz ;)
Oh by the way, we and many others have been working successfully with EtherCAT
on a number of not so small applications for a few years without needing
synchronous IO.
- Richard
On Wednesday 19 October 2011 10:52:03 Jordi Blanch Carles wrote:
In our case, the whole EtherCat loop would be:
ask_for_inputs()<----- ecrt_domain_queue + ecrt_master_send
wait_for_packet_received()
process_inputs()<----- ecrt_master_receive + ecrt_domain_process
make_calculations()
send_outputs()<----- ecrt_domain_queue + ecrt_master_send
wait_for_next_period()
Mit freundlichem Gruß
Richard Hacker
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
