Title is a bit vague as i’m not quite sure how to explain it.
Basically, does RobotC have the issue where if you code an if (btn=1) {var++} and hit the button once, it refreshes multiple times incrementing var multiple times?
How would I solve this? Also, does waitmsc shutdown the cortex from all inputs during the wait?
The way we have done it is to set a Boolean when the button is first detected as down. Then, you add a && !boolean to your if statement, so it only passes when it’s false. For this reason, the true set needs to be after or inside your if statement. Then, when it’s detected as unpressed, you set the boolean as false again. This should make the if only pass once per press.
As for the wait, my guess is probably unless the wait is not on the main thread, but that’s just a guess
AFAIK a wait1msec will only put the one task it is in to sleep for however much time. And the reason the button “presses” more than once is because the code checking for the button is in a loop. So every time it loops, it activates the “button is pressed” branch of code over and over. The way that we fix this is a little different from what StaticShadow said, we put a while loop in the if. So after it does whatever it does when you push the button, it stay stuck until you let go of the button. We do this to prevent conflicting P-loop targets since we use two joysticks. Hope this helped.
Wouldn’t that lock your thread and only let you do one thing at a time? Or do you have different systems on different threads?
Yes, it does lock that particular task(only while holding a button, which we never do) which in our case is actually helpful. All our functions are a press to run macro type thing, so we never have to hold a button
That’s won’t happen if the test is not in a loop.
However, if it is in a loop, it’s not an issue; it’s expected behavior. You simply cannot remove your finger from the button quickly enough for it to be read only once if the test for button pressed is inside a loop.
There are many ways to handle that, but the typical thing to do is to act on a button condition only when the state the button changes. That is, if it wasn’t pressed the previous trip through the loop, but it is in the current pass through the loop, then increment your variable. If it is still pressed next time through the loop, don’t increment your variable.
Basically, you should detect when a button changes, and take any action only when you notice the change.
Ah, so is @StaticShadow 's way of using booleans that sort of “reload” upon release a good example?
We have used a wait1mesc(200), (2/10 of a second) to account for the time it takes a button to be pressed and released very well, across multiple robots, and for multiple functions.
So uh, is bouncing an issue in vex?
There have been instances when limit switches have been used and mechanical stops as a backup where the coding could result in undesired outcomes. It’s more of a coding issue than a driver issue. Code what your drivers want. teach your drivers well.
We have done this many times last year and this year. I don’t know if RobotC does debouncing before populating the SensorValue array, but we have never had trouble where additional debounce code is needed.
I don’t remember whether robotC debounces or not, but it probably does. (@jpearman is your definitive source on this, though many other people will also know the answer.) Nevertheless, this is an issue of button-press dwell time. That is, the time it takes to get through a loop is a lot less than the time it takes a human to press and release a button.
Correct, we use a last state check, and haven’t had issues with bouncing on the signal.
Would this “bouncing” problem get worse as the joystick ages? Our joystick is old and beat up, and I am having a lot of issues with a function being triggered multiple times even with a Boolean storing the button’s previous state.
Last year, we had a newer joystick and didn’t have that problem with essentially the same code (but the little plastic piece keeping the Ethernet cable in for the field broke off, and so it is impossible to use without the field connection constantly falling out…)
I think I might try adding a time delay and see how that works out.
As far as I know, the age of the joystick wouldn’t matter. The time delay is the only reliable way I know of to solve this problem.
