I'm building a small pump system, when the microswitch is actuated the pump should run clockwise when the microswitch is released the pump should run counterclockwise for two seconds.
This is the code I am using but it has a bug. When I switched the main power on, the pump start spinning forever, when I actuate the microswitch it reverses and also spins forever.
Suggestions would be very helpful!
Regards Peter
Here the code I'm using and a link to the schematic:
Any sketch that reads a switch needs to be non-blocking. As mentioned the state change example will help.
You also need to think about the different states your machine can be in. It is always going to have to monitor the switch as that effects the states. One state is that it will be doing nothing except waiting for the switch to be closed. While the switch is closed it will be running the pump and waiting for the switch to open. Then the state will be running the other pump (or backwards) and timing that for two seconds waiting to go back to the state of doing nothing but waiting for the switch to close again. This can all be done by timing using millis. You need to think of things happening in a loop rather than a linear script.
Any sketch that reads a switch needs to be non-blocking.
I know what you mean, but that statement is not entirely accurate. If the one and only thing that the program is doing is waiting for the switch to change state it can block to it's heart's content.
The danger is doing that when it doesn't matter in one program then using the same technique when it does matter in another one. Horses for courses.
The same goes for the infamous delay() command. If you really don't care that the program can do nothing else during the delay() period then it is OK to use it. There are more accurate ways to do nothing for up to 49 and a bit days but if delay() will do what you want then why not use it ?
Delta_G
Thank you very much you set me on the right track.
The code I was using was indeed not very intelligent as you pointed out, it was a forever ongoing loop.
I studied the code you mentioned "State Change Example" and changed it to my situation and everything works flawlessly now.
Below the code I use now, again thank you very much:
int pomp1 = 7;
int pomp2 = 8;
int PWM = 9;
//int micro = 11;
int buttonPin = 11;
// Variables will change:
int buttonPushCounter = 0; // counter for the number of button presses
int buttonState = 0; // current state of the button
int lastButtonState = 0; // previous state of the button
void setup()
{
pinMode(buttonPin, INPUT_PULLUP); // Enable internal pull-up resistor on pin 11
pinMode(pomp1, OUTPUT);
pinMode(pomp2, OUTPUT);
pinMode(PWM, OUTPUT);
}
void loop(){
// read the pushbutton input pin:
buttonState = digitalRead(buttonPin);
// compare the buttonState to its previous state
if (buttonState != lastButtonState) {
// if the state has changed, increment the counter
if (buttonState == LOW) {
// if the current state is LOW then the button
// wend from off to on:
buttonPushCounter++;
digitalWrite(pomp1, HIGH);
digitalWrite(pomp2, LOW);
analogWrite(PWM, 255);
} else {
// if the current state is HIGH then the button
// wend from on to off:
digitalWrite(pomp1, LOW);
digitalWrite(pomp2, HIGH);
analogWrite(PWM, 255);
delay(2000);
digitalWrite(pomp1, LOW);
digitalWrite(pomp2, LOW);
analogWrite(PWM, 255);
}
// Delay a little bit to avoid bouncing
delay(50);
}
// save the current state as the last state,
//for next time through the loop
lastButtonState = buttonState;
}
OK, it works, and that is good, but why use int variables that take 2 bytes for values that will never be greater than 255 (1 byte) ? Also, it would make sense for variables whose value will never change in the program, such as pin numbers, to be declared as const.
Another observation, As the value written to the PWM pin is never anything but 255, why do it over and over again in the loop() function as opposed to once in setup() ?
The answer that I was expecting (hoping for) was that some time in the future the PWM pin would be used to control the speed of the motor, but we shall see when/if the OP replies.
