Prevent spamming of credit button on arcade machine

Hey folks been using Arduinos a while now, I'm still learning.
What I would like to do is for a button on my arcade machine to only register input once every 30 seconds or so. If its been pressed within that allotted time then further input would be ignored. On the machine itself its a pushbutton that's normally open and once its closed briefly it sends a signal to put a credit in the machine.

I hope that makes sense and someone can help!!

Makes sense and for sure doable, but you need to give more info about your circuit

Welcome to the forum

The first thing that you need to do is to detect when the button becomes pressed rather than when it is pressed

See the StateChangeDetection example in the IDE

When the state change occurs, save the value of millis() and ignore further input until the current value of millis() minus the saved value is greater than the required period

I struggled with reliable button-press detection (debouncing) until I read about when the button "becomes released after the button becomes pressed"

Is "becomes released" not necessary?

If the button becoming pressed is used to trigger an action that takes longer than the switch bounce period then no debouncing is required. By the time that the action has taken place then the debouncing will have ended

By the nature of how switches work there is little chance of contact bounce occurring on release of the switch

Use a denounce function whose first step is to ignore the button if it has been pressed recently, and crank that time up to 30000 milliseconds.

As it happens, I very recently posted an example.

See the post, take the link to the simulation. I can't remember if the rest of the thread would be of any interest. I'm in transit, sorry to be rude and not repeat all that here.

The number to bump,up should be obvious, if not, @ me to get my attention again.

HTH

a7

My experience is different. And how little would the chance have to be? If there is any chance, I'd just fix both edges, it's often just a matter of a few code lines to make the handling symmetrical. One I looked at recently only needed to update the timing variable used on every state change, not just the got-pressed one.

Most button libraries handle both, not doing is one of a handful of reasons I flunk a button library.

The wokwi simulates bouncing on both edges.

a7

1 Like

They typically bounce more on the release.

From the Guru of debounce:

1 Like

Hello tobyrieper48

Welcome to the world's best Arduino forum ever.

Post your sketch, well formated, with well-tempered comments and in so called
code tags "< code >" and schematic to see how we can help.

Thanks for your help and above advice. Button debounce, ok so the output can only be triggered once per 30 seconds, any additional closes to ground would put in another credit (which i dont want) ill get back to you all when im at work and will upload my current sketch.

Thank you all

Even if that is true of the switches being used it is irrelevant in this application because it will be 30 seconds before the input is read again

1 Like

Very true and I had meant to mention that in my last post.

My comment was regarding the "nature of switches" for the benefit of others reading the thread as my experiences were much like @xfpd's
It becomes very important in the opposite situation where someone is spamming the button and you do want to catch every button press.

@tobyrieper48 - I've been tinkering with that example. Due to the symmetric handling of the press and release, it takes two debounce periods before the switch press is recognized, at least just now that's what I think is happening. I'll look again, but using 15000 milliseconds should give you the 30 seconds lockout.

But as observed, debouncing is overkill, it's just an easy handy way to do this.

FWIW, non-responsive buttons will drive a high percentage of users insane, never a good thing.

I suggest you to provide some kind of acknowledgment or feedback so there is no mystery as to why the button seems to not work.

a7

The reason why id like to do this is some machines dont have an attract mode on freeplay. As my arcade takes no coins its just an entrance fee. I want the attract mode on all the cabs and some do this only its on credits. So many people go to a game and spam 10 credits have one game then walk off. I think if you die with 30 seconds maybe gaming isnt for you :smile: jk.

So debounce is the one to go for then?

Yes. But not any debounce algorithm, or you might end up with a button you needed to hold for 30000 milliseconds to operate. See my example for one appropriate technique.

If you can tolerate having the action occur every thirty seconds if the button is held down or jammed with a toothpick it is in fact somewhat simpler.

In either case, the button function should be called very frequently.

Call a function like this to check on the button, I remind you this will repeat the action every 30000 milliseconds if the button is held down, you may think that is not a problem.

void button()
{
  static uint32_t lastPressed;
  const uint32_t lockoutTime = 20000;

// button locked out?
  if (millis() - lastPressed < lockoutTime) return;  // too soon, all done

// is the button pressed?
  if (digitalRead(theButtonPin) == HIGH) return;     // nope, all done


// unlocked button is being pressed so
//... do whatever should happen


// here


// and remember when that happened , so it can be locked out for a bit
  lastPressed = millis();
}

I don't know if you ever looked at the simulation. The above is part of the logic with the variable names changed to reflect their new rolls.

Both the function from the simulation and the reduced version of it here can be easily fitted with a feedback mechanism to indicate that the button is not operable. Perhaps a lamp that was green when the button will work, and red when it is locked out.

If you don't provide feedback for a locked out button, all I can suggest is that you use a button that will take the stress to which it will probably subjected. :expressionless:

a7