Pinball Machine Bumper Design

Hi Mark
Another advantage of the 555 approach is button debounce. The trigger input will ignore any more attempts to trigger until the current timing sequence is finished, so no false multiple counts.
Cheers Bob

Hi Jeff,

Yep that approach worked a treat! The solenoid is now pulling down for as long as I tell it to. That makes the ball come away from the bumper at a decent velocity. It is responsive as well. Using interrupt pins is the only way to go.

Don’t know if the code is exactly correct but it definitely works. If anyone has any improvements, I’m all ears. May not be as effective once all components are functioning but I’ll cross that bridge when I come to it.

Thanks very much!

const byte interruptPin1 = 18;
const byte interruptPin2 = 19;
volatile byte state1 = LOW;
volatile byte state2 = LOW;
int score1 = 0;
int solPin1 = 7;
int solPin2 = 8;

void setup() {

pinMode(interruptPin1, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin1), bumper1Hit, RISING);
pinMode(interruptPin2, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin2), bumper2Hit, RISING);
pinMode(solPin1, OUTPUT);
pinMode(solPin2, OUTPUT);

void loop() {

if (state1 == HIGH){
digitalWrite(solPin1, HIGH);
digitalWrite(solPin1, LOW);
score1 = score1 +50;
state1 = LOW;

if (state2 == HIGH){
digitalWrite(solPin2, HIGH);
digitalWrite(solPin2, LOW);
score1 = score1 + 20;
state2 = LOW;


void bumper1Hit() {
state1 = HIGH;

void bumper2Hit(){
state2 = HIGH;

Hi Bob,

Thanks for this suggestion. If I have problems with the arduino method further down the track, I will test with this method. The fact the arduino method doesn’t require more components is attractive to me. Either way, I will need to remake the PCB. Probably should have tested further on a breadboard before getting the first ones made. Space on the PCB is also at a premium so adding components isn’t ideal. As soon as I got boards larger than 100mm x 100mm, the price went up steeply so making them bigger is not really an option.

Thanks for all your help!


Hi Mark

Don’t feel too bad about that. I worked for quite a large company during my working life and have yet to see the time when a board was right first go. They used to go close but when the customer only allows 3 modifications and nil components on the back of the board (all through hole those days) remakes were fairly common. The idea was to get this to one re-do as sometimes the boards could have many layers. When in the development stage some of them looked a bit like a dog’s breakfast with little links everywhere.

Good luck with whichever approach you finally go with. When you get all the bumpers working at once the Arduino might struggle a bit with time but maybe not.

Tip. If you are having an issue with time the Arduino (UNO R3 anyway) has a delay of several µSec at every digitalWrite command while it does some housekeeping (so I read). You can try a command digitalWriteFast to recover most of this time. This apparently bypasses the housekeeping and at the end of the day can be quite a bit faster. All this was the result of some experiments with an Arduino UNO R3 and might be different on a Mega. this could help that little bit that could be the difference.
Cheers Bob

Add on. Just had a quick look at your sketch. If you are switching the Arduino pins to high when a ball strikes (as in your circuit) are you sure you should be setting the interrupt pins high with the PULLUP statement. Doing this will set them high and they will expect a low active surely. You already have physical pull down resistors (R2, R3, R4 etc) on these pins or have you changed things since you published that.

Hi Bob,

Thanks for those suggestions.

Never heard of digitalWriteFast before. I’ll give that a go. I’ll get rid of the pullup statement as well. As you pointed out, that’s only needed when you don’t use the resistor in the button wiring setup. I haven’t changed the design since publishing that schematic so the pullup statement is definitely an error.

Thanks again,

Hi Mark.
You won’t find it easily either.
About 6 months ago I was investigating a significant pulse generation error. The pulses and spaces between were about 4 µSec longer than requested. This produced an error of some 40% in my case. This occurs due to some housekeeping to make sure the pin is not being used for something else etc. There are a couple of ways around this and one of them is the digitalWriteFast command which is found when you dig deep enough.

I started a rather long post re this last December here if you are interested. Complete with oscilloscope screen shots and measurements.
Dec 2022

Dec 2022

Cheers Bob
Well that did not work. If you are interested and want to find it search for

Arduino UNO R3 some limitations

That seemed to work better so try clicking on that link