Joystick Button Issues

[pyr0b0y]

We used the joystick buttons, NOT the triggers, to control motors on our robot. for some reason, when we try and start the motor, it seems to get stuck when we press the button. If i reprogram the button the be a trigger, then there seems to be no problem at all and the motor runs fine in forward and reverse.

are there known issues with these buttons on the joystick???

[JasonF]

We have used buttons to control motors with no problems at all...

If you want to reduce the possibility of a hardware issue, simple probe the correct output in LabView for the Boolean value.

I doubt it is any type of hardware issue. I am not sure what you mean by the motor gets 'stuck'

But I would say: Make sure while your true statement of the IF structure has whatever speed going to the set speed, be sure to Copy the Set Speed and make it a constant of 0 so that they motor does turn off when you disengage the button.

If that doesn't solve it i guess post up your code or try explaining some more symptoms. I can post some simple code but it should be pretty easy to set up.

Hope that helps,

Jason

[pyr0b0y]

For the motors I have them programmed to Button 3 and Button 4. I have double checked my code numerous times and the code is correct because I try the same motor with the trigger button. I have also replaced the motor to see if the motor was faulty, but that was not it either. Whenever I press the button to make the motor go forward, it starts for a spilt second, then gets stuck and stutters its way around; the same happens when I try to go backwards.

[Alan Anderson]

Originally Posted by pyr0b0y

For the motors I have them programmed to Button 3 and Button 4. I have double checked my code numerous times and the code is correct because I try the same motor with the trigger button. I have also replaced the motor to see if the motor was faulty, but that was not it either. Whenever I press the button to make the motor go forward, it starts for a spilt second, then gets stuck and stutters its way around; the same happens when I try to go backwards.

This behavior is consistent with a specific programming error. Check your software to make sure that only buttons 3 and 4 are controlling the motor. What happens if you try pressing the trigger at the same time as one of the other buttons? You might have another spot somewhere in the code where the unpressed trigger is turning the motor off.

[pyr0b0y]

Right now, the programming for the motors is:

Press Button 1, goes forward
Press Button 2, goes backward

This is on both of the left and right joysticks, how can I avoid this problem?

[Cuse]

You could have the nested case structures for the motor, where it ignores input from the other joystick if one is in use.

Eg, if buttons 1 & 2 on Joystick 1 are both false then check for input on 2.

[Greg McKaskle]

Originally Posted by pyr0b0y

... , how can I avoid this problem?

The easiest way is to limit the number of places in your code where you set the speed on a given motor. Use logic to determine the parameters that then flow into a single block to update the motor speed.

The typical, but incorrect approach, is to have conditional code scattered about the teleop loop that computes the value of speed and immediately updates the motor. It seems fine except for the fact that other logic which may not be exclusive is doing similar things elsewhere. When there is nothing to arbitrate the outcome, we call this a race condition .

If you were one of the twelve who attended my advanced LV presentation this will be review, otherwise, my analogy is to give two people in the same room identical remote controls to a common TV. Instruct one of them to turn the tele to channel 12, and the other to channel 34. What outcomes can you forsee? The correct answers include 12, 34, 1234, 3412, 2, 4, 1342, 3124, and there could be others depending on the protocol -- unpredictable. How do you fix it? Have only one remote control or develop an access control mechanism so that only one person can use their remote at a time.

Returning to the motor update issue, delete all but one of the motor updates for a particular motor channel, move this subVI to the right of the teleop loop, and wire the computed values from various logic to that subVI. If you had potentially parallel updates, you will have multiple inputs that will break the wire. Fix the logic so that a given set of inputs produces only one outcome -- you needed to do this anyway as the motor can only have one speed.

If you want more background on this topic, search for race conditions in programming, and especially on LV forums you will get more insight, thought, and religion on this than you probably care for. I suspect other parallel languages will have similar discussions. Or ask more detailed questions here.

Greg McKaskle