Window Motor Problem?

Hi everybody,

Our team is trying to use a window motor on our robot using LabView, but when we program the motor to turn clockwise with one button and counterclockwise with another button, the motor spins perfectly counter clockwise. When we try to spin it clockwise, the motor twitches instead of moving smoothly.
At first we thought it was a jaguar problem, so we replaced it with a victor, but it still has the same problem.

Any thoughts on why?

Thanks,
-Team #2367

did you use the invert function or did you set a constant to -1? If you used the constant change it to the invert function.
the function is located in the programing pallet under numeric.

I don’t think that’s the problem, because we ran both of them counterclockwise (positive), and the motor still ran twitchy when we pressed one button and clean when we pressed the other

Did you try running it right off a battery in both directions and try an identical motor in your setup? It may be a bad motor/gearbox.

You may want to look into this.

We tried that, and it runs smoothly in both directions.

We tried running it with a standard CIM motor, and we still had the same problems, so I don’t think it has anything to do with the locking pins on the window motor.

Can you post a screen shot of you code that is switch the motor from one direction to the other? This sounds like you might accidentally be sending the motor both a forward command and a reverse command. That can result in your speed controller randomly switch from forward to reverse at high speed, thus resulting in your motor twitching.

You beat me to the punch with testing with a CIM. Good job. That definitely isolates it to a programming or electrical problem.

It seems like a coding problem, but I can’t figure out what the problem is at all. We tried both a Victor and a Jaguar, so I don’t think that is the problem. The code is very standard, I just wired two buttons to a case block. And for one of them, I ran the motor forward when it was true, and backward when it was false. The motor itself is upside down, so it doesn’t work properly when the motor is turning forward, but it works well in reverse.

I’m having difficulty parsing what you’re doing. You’ve wired two buttons to one case block? Are you having one button that turns the motor on/off and the second one that picks the direction? I think it’d be a lot clearer if you posted the VI or a screenshot of it.

I’m really sorry, but my code’s all at the lab, so this is the best that can do for now, but I’ll try to explain it as well as I can.

I have 2 case blocks. One case block is wired to button 3 on our joystick. When that case is true, it sets the motor speed to -0.9. That one works smoothly. I also have another case block which is wired to button 4 on our joystick. When that case is true, it sets the motor speed to 0.9. When I press that button, the motor moves in the right direction, but it stops and jerks forward and then stops again. Note that I haven’t put anything in the false part of the case blocks.

Thanks so much for your help and once again I’m really sorry that I can’t post a screen shot right now.

That’s certainly a recipe for weirdness if you’re pressing both buttons at once. Also, how on earth does your motor stop after you let go of a button? If you let go of the counter clockwise button, does the motor stop or keep going? If your motor stops then you’re clearly setting the motor speed to 0 somewhere else, since it’s not in your false cases. If you’re setting speed to 0 elsewhere, then your button 3 code is beating out the zero speed code and keeping things moving. Your button 4 code occasionally loses to the zero speed code and thus sometimes the motor stops, and sometimes it moves. Assuming you’re setting speed to 0 somewhere.

What I like to do for programming two buttons to turn a motor is to pick a dominant case. That means that you pick one of the buttons that “wins” if both buttons are pressed. Then you can pretty easily use two Select blocks to set the motor speed. See my attached code snippet, in which button 3 “wins” and gets final say in the motor speed.

Motor Snippet.png


Motor Snippet.png

You could try switching imput buttons on your joystick to see if that helps also. I know our gamepads had a glitchy button on it. You might want to put the -1 value and then invert that into you motor output to see if it works also.

Wait, so if I set my motor speed to 0 when false in the case block for button 3, will it affect the motor when the button 4 case block is true?

Yeah, we tried both of those things, and neither worked. :frowning:

What I’ve always done is just put the numbers in the case statements, with the Set VI outside the case. The true cases have the values to set the motor to, and the false cases both have 0 in it. Just to the right of the case, I put an addition operator in. That way, if one button is pressed, it adds 0, not affecting the output. 0+0 = 0, x+0 = x, and x+y=0. (Of course, this only works when both positive and negative values are the same…)

Edit: I also use the Select statement for the values, not just cases. Keep forgetting I usually put global sets in there too.

If you have two completely separate case blocks for button 3 and 4, then yes, the false case in the button 3 block will affect button 4 even if button 4 is true. See my attached snippet. The top two show the cases in the case blocks. The bottom shows what will run when button 3 is false and button 4 is true. Both of those case blocks will run, which means you’re trying to set the motor speed to 0 and set the motor speed to 0.9 at the same time. The results of trying to set the motor to two different speeds simultaneously are not particularly predictable.

Cecil’s suggestion of putting the motor set block outside of the cases is also a good one. Then you know that you only have one motor set and it’s only going to run once. Then you just have to figure out how to send it the appropriate value. It makes it pretty obvious if your value selection method isn’t valid because you’ll end up trying to wire two thing to the same input, which labview will complain about.





I got it working! Thanks for your help guys! I think something was overriding the reverse command, but I couldn’t figure out what it was, so I just wired it to one SetMotorSpeed like you guys said to.

Just as long as you remember this and apply that design pattern to the rest of your systems so you don’t have the same problem in the future.