Hi Graeme, thanks for the detailed reply!
With my now modified cycle, I get a difference of about 4.45 cycles. As I now receive the current position before I send out the next target position (while it was the opposite way before), it makes sense it is one cycle more. But I compare the current position I receive at the begin of the cycle with the target position I send out right afterwards (I do not compare with the one generated later in the cycle and send out the next cycle!) Therefore, I think, it is still not 100% clear: - I would assume that in my now modified cycle (when following your example) I have 3 cycles delay, not 4. - SYNC0 offset does not affect the 0.x cycle at all. This however makes sense to me, as SYNC0 both affects the moment the target position is activated AND the moment the current position is captured. So modifying it will just move BOTH events together, making it invisible when comparing like this (of course, the real axis position will move relative to the real time). - The reason for the 0.45 cycles is probably some internal delay in the drive between activating target position and capturing current position? <> What you need to do is find the Following Error PDO index, add that to <> your drive PDO data, and use it. I read this now (also 0x60f4:0). It is however not giving me the delay I am observing but the servo error due to axis regulation tuning. If I substract the following error from the current position and then do the compare of target position and modified current position I get very stable a delay of 4.456x cycles during constand speed movement and just slightly changing values during strong accleration. So I can measure the delay much more precisely. Thanks for your help and best regards! -- . -Michael _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
