I'd be inclined to refactor the thing into a state machine (search the forums). But for less work, when you set OverrideState to be true, store the current value of millis in a global unsigned long. In the section you run when OverrideState is true do something like this:
wildbill:
I'd be inclined to refactor the thing into a state machine (search the forums). But for less work, when you set OverrideState to be true, store the current value of millis in a global unsigned long. In the section you run when OverrideState is true do something like this:
if(millis()-TimeOverrideWasInvoked > 30000UL)
{
Tone(Speaker,100);
}
Ok, I'll try this out when I'm back in front of my Arduino
rocketboy001:
2) I understand that that the use of the goto is frowned upon (though I did not know hoe vehement people were about it :)). I used it 'cause it worked and as mentioned here (http://arduino.cc/en/Reference/Goto) I did not use in "unrestrained." I'm open to suggestions on how to eliminate this.
That was popular before structured programming paradigm came along to save the day when code became hundreds of lines long that resembles a certain type of poorly cooked Italian noodle. You have to have well-defined entrance and exit points in your code for debugging. It's not an optional writing style. I'll use language analogy once again. Goto was like middle English
Object-oriented programming didn't come out of a fad either. It was absolutely necessary to manage even larger projects and make code stay independent and reusable like modules. Then more paradigm that I don't know for even larger and more flexible projects.
rocketboy001:
... it felt like your first post was dedicated to detailing how stupid I am.
I want you to understand that I look at about 20 to 30 posts a day with programming questions. Once I read "it doesn't work" and browse through the code and see some obvious problems, for example where you are comparing pin numbers instead of reading from those pins and comparing the results, I usually quote the problem code, with a hint about how to fix it, and then stop reading. I'm not being paid for this, you know.
I never called you "stupid".
If I had really wanted to make you look small I would have kept going and found all the other errors (if any).
I'm a believer in teaching people to fish rather than giving them a fish, so I don't usually try to simply hand back corrected code.
You might want to reconsider telling someone on a forum they don't understand "the basics" especially when you say:
I'm not a programmer ...
If you are not a programmer, how do you know I don't understand the basics?
rocketboy001:
2) I understand that that the use of the goto is frowned upon (though I did not know hoe vehement people were about it :)). I used it 'cause it worked and as mentioned here (http://arduino.cc/en/Reference/Goto) I did not use in "unrestrained." I'm open to suggestions on how to eliminate this.
That was popular before structured programming paradigm came along to save the day when code became hundreds of lines long that resembles a certain type of poorly cooked Italian noodle. You have to have well-defined entrance and exit points in your code for debugging. It's not an optional writing style. I'll use language analogy once again. Goto was like middle English
Object-oriented programming didn't come out of a fad either. It was absolutely necessary to manage even larger projects and make code stay independent and reusable like modules. Then more paradigm that I don't know for even larger and more flexible projects.
I get why you would not want to use goto, I just could not come up with another way... and it worked so.
Although, that's not entirely true I did consider another option. Currently where goto is used the code is:
if (DoorClose1 == true) {
while (DoorCloseDelayVal != DoorCloseDelay){
tone(Speaker,100);
digitalWrite(DoorClosingLED, HIGH);
delay(500);
tone(Speaker,200);
digitalWrite(DoorClosingLED, LOW);
delay(500);
DoorCloseDelayVal ++;
if (digitalRead(OverrideSW) && digitalRead(DoorOpenedSW)) {
[b]goto override;[/b]
}
if (CloseAttemptsVal == CloseAttempts) {
[b]goto override;[/b]
}
}
Well, first and foremost I do appreciate your time. You've pushed me to try to come up with something other than the goto. And you pointed out the issue with how I was reading the state of the PINs.
That said, in case you didn't see my other posts - I never said "it doesn't work" In fact what I said in my initial post was that it does work but that I'm not sure how to go about adding this specific function (that being a beep every x # of min. during the override).
Again, I honestly thought that you were telling me that I should not be naming/defining PINs. I'm sorry about my confusion on this but that's where my "basic stuff" quip came into play because I was siting here thinking "every single example I've looked at does this..." Hopefully that clears up why I said that and for what it's worth I take it back. You'll also have to excuse my confusion when you (and a number of other people) insisted that what I have will not work because coming into this it all did (including PIR1, PIR2 == HIGH). Now it's been pointed out that I may just not be testing enough to catch the error but I assure you that as far as I know it works. I will however make the corrections you and others have suggested.
Lastly, I'm not expecting to be spoon fed. Guidance is nice though.
Hope that we can move past the initial confusion and that once I figure out how to get my code working without the goto you'll be able to stomach my code
Just a reminder: a general block diagram is independent from the fact you are using a "computer" to implement it. If I want to stand outside your garage holding all wires, I should be able to use the block diagram to carry out your project too. Once you have a sketch, try to get more specific in your next block diagram and then plan on how to write code to have arduino do it, instead of me.
Ok, went back to the drawing board a bit. I got rid of the goto, replaced it with a function, and also fixed the issue with the way I was referencing the state of the PINs. Using the suggestions given as guidance I was able to set it up so that there is a beep every x seconds while the override is active.
Shouldn't the Calibrate function be called from setup rather than loop? Clearly either will work, but why bother checking for it in loop when it's a startup activity only?
wildbill:
Shouldn't the Calibrate function be called from setup rather than loop? Clearly either will work, but why bother checking for it in loop when it's a startup activity only?
I was thinking that, but it has to be called 40 times. A 'for' loop might look better though, called from setup.
[quote author=Nick Gammon link=topic=124606.msg952005#msg952005 date=1349900411]
Does it work?
In general in cases like this:
if (DoorCloseWarn == true) {
Warn(); // go to the Warn function
Booleans can only be true or false, so testing for "== true" is a bit redundant. How about:
if (DoorCloseWarn) {
Warn(); // go to the Warn function
It does work... both my uncle (who I wrote it for) have tested it and it all seems to function correctly. Good point on the DoorCloseWarn == true.
Thanks,
Adam
[/quote]
True. Honestly, I hadn't considered moving it outside the loop because I was not aware of how to work things outside of the loop. I'll have to play with your suggestion - I guess the benefit is that it's one less thing that has to be checked in the loop.