Good discussion ...

Originally Posted by
Melanie
There is another way of thinking here Alain...
Once a switch has closed (as detected by the first IF/THEN) then the assumption is that whatever event caused it to close (or open) is not a False Alarm and the event intended to happen (eg a User pressing a button). You therefore need no futher IF/THEN's to see if the contacts are still closed after the debounce time period expries.
All you have to do is delay looking at that switch again for a period of time greater than any possible contact bounce to ensure you don't register that event a second time (as would happen if you used interrupts for example).
Now the delay time is really down to the application. I tend to use 100mS for Keyboard Buttons, because that gives an 'auto-repeat' of 10cps which is quite nice when viewed on a display. Naturally, if you're timing something that happens a lot quicker, then you need to reduce the bounce delay time, but if you get it too short, you'll run into the multiple contact closure problem.
It's difficult to guage and is done mainly by look/see and a bit of experience because different switches (be they contacts on a Switch, Relay or a Reed) all exhibit different closure properties and have different bounce periods. Best method I've found is to overkill the delay as much as possible.
The best method for registering an event, but discarding any False Alarms, is to see how long a switch remains closed over a period of time. That then will require multiple IF/THEN's both at the beginning and at the end of the debounce period.
Hi, Mel,
Here, the problem is we do not know for how long the magnet will be close to the reed switch ...
so, how to fix a reliable debouncing time ... ???
But we know one thing : if the reed switch is triggered, say 20 or 50ms long ( real debouncing ) ... the magnet is really here !!!
So, let's consider the triggering is then real.
We do not want new triggerings before some times ( That's THE problem ), even the magnet is still here ... right ???.
Let's say we allow few seconds for the magnet to go further ... before testing it once more.
If tested close ... the train is still here, stopped or so : What to do ????
If tested Open ... let's go on our program.
.............................
Back to PicBasic programming, we see here that it's the original scenario which is wrong, cause it doesn't allow a correct work of the Hardware connected.
In primary schools, our teachers always repeated us a clearly written problem has already found half its solution ...
Alain
Last edited by Acetronics2; - 18th May 2006 at 09:36.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
Bookmarks