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 _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
