Just saw someone talking about this in another thread, and without reason the next day, similar things started to happen to our drive.
Taka a look:
I’m not sure why this is happening. Our drive used to be very smooth and responsive just a couple days ago. We’ve isolated the problem to be the motors, as we tried different motor controllers and cortexes. Any solutions?
Did you change your code in the last couple days?
A gear in the motor could be broken.
We are actually also experiencing the same problem, but on our catapult. We know it is not the code because it runs the same exact motor commands as the other 5 motors on the catapult. The strange part about ours is that when we run the drive, it also makes the “problematic” motor twitch, meaning when we drive, it initiates this twitching. It also happens with running the catapult. We’ve tried different motor controllers. Any suggestions?
I’ve talked to some people about this, and @PixelToast says that the new RobotC update could be inducing context switching, meaning that since we have an infinite while loop with no delay, RobotC stops my code to let the CPU handle other tasks. So apparently I need to add a delay at the end of my while loop. This seems like a possible solution that could be tested true if we just initialize motor speed to be 127 in task main and have an endless while loop after it. Still, IDK, I feel like this may not be the right answer, however it seems very plausible since the only variable that’s changed since it was working is the new update.
In all of the four motors simultaneously?
I won’t be able to test anything until monday. 
Post the code
task main() {
while() {
motor[2] = vexRT[Ch2];
if (vexRT[Btn5U]) {
motor[2] = 127;
}
if (vexRT[Btn5D]) {
motor[2] = -127;
}
}
}
I initially thought that the code was setting two different values at once. It’s not. In the video, we moved Joystick Ch3 to 127 and not the buttons. Since no button was pressed, motor2 was only updated by vexRT continuously.
@Infinity Minus 1 Thx 
I would have to agree with @PixelToast, due to the fact that this happened to us about a day after we updated.
Just wondering… Not sure if it will makes a difference…
How about adding an “else” statement after your “if” ?
Eg. Else motor [2] = 0
I know it looks redundant, but I am just wondering could it be the processor still retains the initial instruction of 127, and then it received the 2nd instruction of -127?
It’s actually not redundant. The only thing it can do is make the problem worse.
In the video, you can see that I only use the joystick. With my current code, the vexRT should update a motor and since we don’t press any buttons the code shouldn’t update anything else. But, with your code, (of adding an else statement) the motor will constantly switch from 127 speed to 0 speed. However good idea.
I would’ve used much better code to test it. Code that deosn’t have as many things that can go wrong. The thing is, I won’t be able to test anything until monday. I’m trying to give you guys the most accurate description of the situation possible, so that you are able to debug everything that could’ve gone wrong properly. If I could test new code now, I would do it.
Not sure i will call it worse.
But thought that’s the purpose of buttons? It will only activate when pressed? No?
@meng the code was actually used to test something else. I didn’t feel like making another test program so I reused this, but to test this I only needed the joystick.
Unpressed buttons constantly send 0, so an else statement would definitely create an issue where motor[2] would be set to the value of Ch2 and whatever the else value is. Given that the motor in the video is constantly receiving a 0 value in addition to the Ch2 value, I’d say that your if statements are causing the problem (even though they should only be true when the button is pressed.)
I am not sure why you want a motor controlled by both buttons and joystick, but you can combine the code to one instruction to eliminate the spaz. This is the same as what (I think) you were trying to write:
motor[2] = vexRT[Ch2] + ( (vexRT[Btn5U] - vexRT[Btn5D]) * 127 );
This code will work, but it might behave differently when the joystick reads a nonzero number and a button is pressed at the same time. I’d rather do something like this:
if(vexRT[Btn5U] ^ vexRT[Btn5D] {
if(vexRT[Btn5U])
motor[2] = 127;
else
motor[2] = -127;
}
else
motor[2] = vexRT[Ch2];
Lets not start crazy rumors. The RobotC task management has not been changed in a long time, V4.55 should behave the same as V4.52 (and wrt to task management probably the same as V3.XX).
Using an infinite loop without a delay, although being a bad programming habit, should not cause any motor problems. If it does then there is probably something else wrong in the code. Perhaps see some of the tips in this thread.
https://vexforum.com/t/robotc-bad-programming-habits/28357/1
May not even be the code, We had the issue when we geared out chassis too fast last year, it would run for a sec than “stall/twitch” just like that… May be an issue if it is happening that easily
I think the gear might be stripped in the motor. The dome shaped teeth are never good they can last for a little while but then they stripped. Always when you buy the motors remember to change the internal gears to the straight teeth.
I personally follow this structure for buttons.
// Lift going up
if (JOY_TRIG_LU == 1 && JOY_TRIG_LD != 1 && JOY_TRIG_RU != 1)
{
if (SensorValue[liftLeft] < LIFT_UPPER_LIMIT){
setLift(127);
} else{
setLift(0);
}
}
// Lift going down
if (JOY_TRIG_LU != 1 && JOY_TRIG_LD == 1 && JOY_TRIG_RU != 1)
{
if (SensorValue[liftLeft] > LIFT_LOWER_LIMIT){
setLift(-127);
}else{
setLift(0);
}
}
// Lift up and hold
if (JOY_TRIG_LU != 1 && JOY_TRIG_LD != 1 && JOY_TRIG_RU == 1)
{
if (SensorValue[liftLeft] < LIFT_HALF_LIMIT){
setLift(127);
} else{
setLift(0);
}
}
// No lift buttons pressed
if (JOY_TRIG_LU != 1 && JOY_TRIG_LD != 1 && JOY_TRIG_RU != 1)
{
setLift(0);
}
It may not be the prettiest, but checks all user input that can control that function in every statement. So only what I want to happen will happen
In the code, it says button 5d has to be pressed.
In the video, the joystick ch3 is being used.
Did you use an if statement as well for the code in the video?
So just ran this snippet of code:
task() {
while() {
motor[port1] = 127;
}
}
And sure enough, there weren’t any problems.
The question now, remains, why does this code not work?
task main() {
while() {
motor[2] = vexRT[Ch2];
if (vexRT[Btn5U]) {
motor[2] = 127;
}
if (vexRT[Btn5D]) {
motor[2] = -127;
}
}
}
I’ve gone through it multiple times, and it doesn’t make sense to me. Why, when I use the joystick only, does this code cause the motor to not function properly?