In order to avoid encoder drift, you want to remove the encoder reset from your return blocks. You wait until encoder value zero is reached and then stop the motor and reset the encoder to zero. If the commands execute fast enough, then the encoder value is still zero when you reset it. In this case the command is useless. If execution is not fast enough, then encoder value will drift with respect to physical position.
You could use the nMotorEncoderTarget variable in order to perform the task. However, be aware that the value is not understood as absolute target position but as a number of encoder increments to advance.
This has some drift implications as well. Consider the ROBOTC example NXT Position Control with the suggested "hand of a clock" robot design. You will find that you can create a permanent delay in the hand by blocking it for one or more loop iterations. For a clock, such relative, incremental position control is not really an ideal solution. Absolute control is better.
However, I do not know of a smart way to implement it. My solution consists of a PD control that forces the moter to go to a given absolute encoder value.
This code implements an absolute position control for motorA. The example sets the motor to a random angle every 500 ms.
You can go to any absolute target encoder value by setting t to that value. There will be no drift due to overshoot or external influences.
Best regards, Martin Kraska
