[etherlab-users] Cycle time

Massimo Mancin Massimo.Mancin at syco.it
Tue Feb 3 13:15:24 CET 2009


Hello Florian,

I agree with you looking at the tests with sampling period lower than 1 
Millisecond,
But what do you think about the 10 Milliseconds test ?
Why after 10 Milliseconds I can't read in ther Trasmit PDO the value I sent 
in the same variable, present in the Receive PDO, 10 Milliseconds earlier ?

  Period = 10 Milliseconds
 Counter 
|Time[microSec]|TargetVelocityWrite|TargetVelocityRead|CommandedVelocity
 1000    |      0      |   1000             |      0           |      0
 1001    |   9999      |   1001             |      0           |      0
 1002    |  20020      |   1002             |   1000           |   1000
 1003    |  30001      |   1003             |   1001           |   1001
 1004    |  39999      |   1004             |   1002           |   1002
 1005    |  49999      |   1005             |   1003           |   1003
 1006    |  59999      |   1006             |   1004           |   1004

Best regards,

Massimo Mancin

----- Original Message ----- 
From: "Florian Pose" <fp at igh-essen.com>
To: "Massimo Mancin" <Massimo.Mancin at syco.it>
Cc: <etherlab-users at etherlab.org>
Sent: Tuesday, February 03, 2009 11:59 AM
Subject: Re: [etherlab-users] Cycle time


> 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);
>
> -- 
> Best regards,
> Florian Pose
>
> http://etherlab.org
> 




More information about the Etherlab-users mailing list