I am needing to make accurate turns. I have looked at the forum and read on resetting the motor encoders to 0.

It appears that the motor is over-rotating. 360 encoder ticks is WAY too many. 300 is close but still too much...it is visually evident by watching a tire attached to the motor that it is over-rotating.

360 encoder turns on slaved motors with a -100 turn index gives me more than 180 degree turn (about 210 degrees).

What am I doing wrong? I have braking on (in preferences and declared in the program). I have tried the slave motors and individually powered motors with opposite signs (+50, -50)...but the fact that you can just pick a spot on the motor and SEE that it rotates too far is getting me.

Any help would be appreciated.

Hi,

I was trying the nmotorencodertarget function to instruct the motors to turn to an accurate position. however, I have failed, for the same reason you've told.

Since I was working on a plotter that requires quite accurate positioning I have created my own task to control the motors to reach a specific encoder value.

This task is executed a few hundred times a second (execution may take 1 msec or so and then it waits one more msec). The main task simply sets the target[i] variable like the pen up function here:

It is of course possible to set targets for two motors at the same time. Since in my case speed was not an important factor the constants MFAST was set to 20 and MSLOW was set to 10. In such slow speed the motors were capable to reach their target quite well therefore the constant CLOSE (which is actually the tolerance) is zero.

Realize that this task is more autonomous than RobotC's built in nmotorencodertarget. Using the built in function you first set the target then start the motors. My implementation strarts the motor every time the position does not match the target -- even if an external torque turns the motor axle. Applying a constant torque on the motor axle (e.g. in a poorly designed crane) my solution might start to "oscillate".

Eh, I can see this (latest) version lacks the tolerance I have mistakenly referred the parameter CLOSE as if it were tolerance. No it is not, it is the distance when the task reduces speed to MSLOW.

Tolerance here is hardwired to zero but it can be a parameter easily.

Correct operation of this automated motor control requires initialization: