Hi Massimo;
Something you need to keep in mind when communicating with any complex
EtherCAT device is that when you read/write to process data, you are
actually accessing a shared memory block used to communicate between the
main processor in the target and the EtherCAT MAC layer.
The processor on the EtherCAT slave will transfer values into and out of
this shared memory area some some fixed update rate. If you write
values faster then the slave can consume them, then some of the data you
write will be lost. If you attempt to read data faster then the save
can update it, then you will read redundant values.
The update rate at which we process data on our servo amplifier is
different for different objects. Some objects are updated at our
current loop rate of 16kHz. Others are updated at the main position
loop rate of 4kHz. Some objects are handled in a background task which
runs at 1kHz. The update rate for any particular object is based on how
it's used and how much calculation is required on our processor to
update it. This object prioritization allows us to make most of the
drives object dictionary available for PDO mapping without jeopardizing
drive performance.
I tried out the example program that you posted and did notice one
strange effect that I can't explain. In the example you posted, you
seem to be updating the process data every 10ms. In your printout at
the end, you show a two cycle delay in receiving a response. This is
one cycle longer then I would expect.
I logged the actual EtherCAT messages being sent using wireshark and
confirmed that the update values are actually being sent from the drive
on the cycle following your write. This is one cycle faster then your
debug output suggests and is what I would expect from the drive. I
don't know why you are seeing the data late.
The correct drive behavior can be seen fairly easily if you log the
messages using wireshark. Just find the block of messages that
corresponds to your process data updates and look at when the new data
is being sent back from the drive. For a slow update period like 10ms,
this should always be on the following message.
Rgds,
Steve
Florian Pose wrote:
Hallo Massimo,
On Mon, Feb 02, 2009 at 04:23:58PM +0100, Massimo Mancin wrote:
Some one can explain me why we have such a latency and we cannot
achieve a sampling period less than 1 millisecond.
this is not a master limitation.
Period = 100 Microseconds
Counter
|Time[microSec]|TargetVelocityWrite|TargetVelocityRead|CommandedVelocity
1000 | 0 | 1000 | 0 | 0
1001 | 100 | 1001 | 0 | 0
1002 | 219 | 1002 | 0 | 0
1003 | 300 | 1003 | 1000 | 0
1004 | 400 | 1004 | 1000 | 0
1005 | 500 | 1005 | 1000 | 0
1006 | 600 | 1006 | 1000 | 0
1007 | 703 | 1007 | 1000 | 0
1008 | 800 | 1008 | 1000 | 0
1009 | 900 | 1009 | 1000 | 0
1010 | 999 | 1010 | 1000 | 0
1011 | 1099 | 1011 | 1008 | 1006
this looks as the Accelnet has an internal computing cycle of about 300
us. I'm sure that Jim or Steven can give you a statement about this, as
they know their device better than I do. ;-)
BTW, you should no do this,
status = (*(uint16_t*) (domain1_pd + off_accelnet_rx + 1));
because EtherCAT data are always little-endian. If you use the
EC_READ_* macros, you are on the safe side:
status = EC_READ_U16(domain1_pd + off_accelnet_rx + 1);
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
