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!
Mark
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);
Serial.begin(9600);
pinMode(solPin1, OUTPUT);
pinMode(solPin2, OUTPUT);
}
void loop() {
Serial.println(score1);
if (state1 == HIGH){
digitalWrite(solPin1, HIGH);
delay(100);
digitalWrite(solPin1, LOW);
score1 = score1 +50;
state1 = LOW;
}
if (state2 == HIGH){
digitalWrite(solPin2, HIGH);
delay(100);
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!
Cheers,
Mark
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,
Mark
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