setMotorTarget...WaitUntilMotorStop Doesn't always Work


We have had the same issue in the past with getting to position on RobotC graphical. Basically, when you have a test condition like check for zero velocity, you should place a command just before to ensure it has a non-zero velocity. The reason being, these are time based when they drop out of the initial move command and if anything makes you have a longer time, it will fall right through your zero velocity test since it never got moving.

We do this type of thing for any sensor based command that uses a time delay in the low level code as it’s means for thinking it actually did something.

Once you do this, they work fine.


Thank you TriDragon. Would you be able to provide a code snippet with this example?


My kids have the same problem. I think the problem is that when you’re checking if the motor has stopped it hasn’t even started yet. I put a short tenth of a second wait after the set mode Target commands and then it seems to work all the time. In other words, you need to get the motors started before you check if they’ve stopped.




Yes, but using sensors is better than using timebase because you are sure the same sensor/condition that you check for true was also checked for false. But you are our nemesis for State’s so forget I said this :slight_smile:


Yes that’s better and certainly a little faster too… And I’ve come to have a very deep regard for second place. :grinning::grinning::grinning:


yes, notice that the macro waitUntilMotorStop has a 100mS delay before testing the flag. In graphical you would need to add that delay before testing the flag.


Thank you for the code snippet. I updated my code to incorporate your suggestions above. I ran the code 5 separate times. The first two times it ran with success. The third , fourth, and fifth time it hung up on the wait.

void moveArm(int distance, int speed)
setMotorTarget(armmotor, distance, speed);
setMotorTarget(armmotor2, distance, speed);
waitUntil(getMotorZeroVelocity(armmotor) == false);
waitUntil(getMotorZeroVelocity(armmotor) == true);
waitUntil(getMotorZeroVelocity(armmotor2) == true);


By “hung up on the wait” you mean the == false wait?
If so, was the motor moving?


Try an approach like this.

#pragma config(Motor,  motor1,          armmotor,      tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor2,          armmotor2,     tmotorVexIQ, PIDControl, encoder)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

void moveArm(int distance, int speed){
  long thresholdForDone = 6;
  long delta;
  setMotorTarget(armmotor, distance, speed);
  setMotorTarget(armmotor2, distance, speed);
  do {
    delta = abs( getMotorEncoder( armmotor ) - distance );

    displayString(0, "target %4d", distance );    
    displayString(1, "pos    %4d", getMotorEncoder( armmotor ) );    
    displayString(2, "delta  %4d", delta );    
  } while( delta > thresholdForDone );
  // optionally stop motors here

task main()
    // test code
    for(int i=0;i<20;i++) {
      moveArm(-400, 100);
      moveArm(-130, 50);


It stopped on one of the WaitUntil… statements. The motors had stopped running. I’ll give jpearman’s suggestion a spin and let you know how it turns out.


you may need to make this number larger, look at the value of delta as the motor moves to determine that.

long thresholdForDone = 6;


This is Vex IQ correct?


This is VEX IQ.

I applied your code and the first arm movement required a delta of 6, but the second required a delta of 18, the first time I ran it. The second time I ran it, the first arm movement required a delta of 6, but the second required a delta of 20.


It appears, though, that this is what I was looking for. Once I adjusted the values, the code has run correctly (in my kitchen) five times straight. Heading to the lab shortly to run it on our playing field. Thank you all for your insights and willingness to help me learn! If all goes well tonight, I’ll mark this case closed.

My last question is this: how on earth would a 5th or 6th grader figure this out? I’m a software developer with 30 years of experience… is there a curriculum or other learning tools I can share with the kids and other coaches at my school?


This is really a question for @DanMantz. This is/has been a sticking point with me for years. The average/plus average roboteer can do most of this on their own. But when you get to this kind of interaction there isn’t any choice but to be able to understand whats going on.

Key thing is that the robot is dealing with the physical world with heat, friction, varying batter voltages and current, play in the encoders, analog to digital conversions, etc. It’s often the little fudge factors (or in this case threshholdForDone) to figure it out. We were doing a similar thing, and ended up changing the distance by another 5 and it worked.

On the plus note, now that you and more importantly they have been through it, it will stick and give you something to think about.

Good luck!


How heavy is this arm ? Some pictures would help us understand why the motors are struggling to achieve the target values. Is the first or second move working against gravity ?


Our kids, by the time they are through high school, have a very good understanding of PID control for all of these reasons.

For elementary, we focus on errors due to light intensity, gear lash, etc… They seem to be able to understand that very well and see the negative effects of certain things.

For IQ I have them write in Graphical RobotC, but show the C listing and the C source (which is where you will see the delays and such). This allows them to see what it runs into as a pre-cursor to VRC for us.

Some of these coding things for kids are equivalent to asking the elementary kids to remove some of the sprockets/gears from an axle (if you’ve tried you know what I mean)


not sure if anyone has already posted this bc im too lazy to read all of it, but way back in vex iq, i think i remember the command being waitUntilMotorMoveComplete(motorName); instead of waitUntilMotorStop(motorName);

hope that’s helpful!


VThe other point that I wanted to make that RobotC is very full featured, we can tweek about every knob there is to tweek. Most people are under the wrong impression that RobotC is a toy language. In fact as a purpose built language for robotics with full API capability it is very impressive.

All the more reason to be sad that VEX is not keeping a proven product, but jumping into something that won’t be ready for prime time until 2022.