[etherlab-users] Cycle time

[Stephen Glow]

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);
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20090203/cf84516d/attachment-0005.htm>