Go Down

Topic: Need delay after digitalRead to make variables work (Read 14778 times) previous topic - next topic

mromani

As uwe (moderator) would probably put it, crystal ball time! :P

nickgammon


My hardware works.  It works the way I think it should.  I do think there is an arduino bug here however. 


Quote
Code: [Select]
  delay(20);  // This delay makes the variables reflect the correct value.


You have to get out of your head the idea that it takes 20 milliseconds for variables "to reflect the correct value".  What you are suggesting is that it takes 320,000 clock cycles (since the speed of the processor is 16 MHz, then you will get 320,000 cycles in 20 Ms : 16,000,000 * 0.020). Since most instructions take 1 or 2 cycles, your theory is that it takes 160,000 instructions to move "true" or "false" into a variable. I'm afraid not. People would have noticed that major design flaw by now.

You also have to get out of your head the idea that your switch isn't bouncing. It will bounce. Maybe after 20 seconds it has stopped bouncing but that isn't the same as saying "they are not bouncing".
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

cmiyc


They are not bouncing.  As I said before.  Once they are pressed it is 20 seconds before the code is question gets executed again.  At that point (which is 20 seconds approx) deployPressed and armDown are both still true but they should not be.


Yes you are right.  It *must* be a bug in the Arduino.  Nearly 1 million have shipped and you're the first person to stumble across the "takes 20ms to read a switch" bug.

-or-

Something is happening with your hardware you don't fully understand.

Which is the most likely?

1.  Now on the 3rd page, nothing new has been posted since the first couple of posts.
2.  Your only claim that no bouncing is occurring is that Serial.print() says so.  Well, Serial.print() is effectively a de-bounce delay.
3.  Two people (myself included) have suggest a hardware method to prove if it is bouncing or not (hint: capacitors.)
4.  Your description of the issue is absolutely consistant with a hardware issue:  e.g. bouncing 
5.  The inconsistency in your code and your descriptions is making it exceptionally difficult to follow.  "When the button is pressed and the pin is high and the variable is false, I see something 20 seconds later." 

Your code would be easier to follow if
a) you used constants to define your pin numbers.  digitalRead(6) means nothing to anyone except the avr-gcc compiler.
b) you stuck to "high" or "true" along with their negative counterpart "low" or "false."  Don't mix between the two.  Sure the compiler sees them as the same thing, but it makes it difficult for dumb humans to follow, especially if you dont:
c)  Consistently refer to your buttons as "pressed" or "high".  Don't go mixing pressed/unpressed/high/low especially when you are inverting inputs with pull-ups.  I can't tell what you mean by "high" in the random context you use it.
Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

PeterH

At first glance the logic in the code looks convoluted, but correct.

I notice that you only turn the motor on and off, there is no direction set. How does the retract cycle work? The only solutions I can imagine involve using the limit switches to reverse motor polarity and there would be ample scope for a circuit design fault there. So can you clarify exactly how these switches and motors are connected and driven?

I'm also curious to know why you're using an Arduino. Did you consider just using the momentary switches to close a self-energising circuit and the limit switches to open it? I would have thought that with a little thought you could get this working without any electronics.

freakdaddy

It works on a cam system so the direction is always the same yet it both deploys and retracts.  Like an animated figure might do.  The arduino is there because the design does more than extend the arm.  This is was just the first phase I am working on.

freakdaddy



My hardware works.  It works the way I think it should.  I do think there is an arduino bug here however. 


Quote
Code: [Select]
  delay(20);  // This delay makes the variables reflect the correct value.


You have to get out of your head the idea that it takes 20 milliseconds for variables "to reflect the correct value".  What you are suggesting is that it takes 320,000 clock cycles (since the speed of the processor is 16 MHz, then you will get 320,000 cycles in 20 Ms : 16,000,000 * 0.020). Since most instructions take 1 or 2 cycles, your theory is that it takes 160,000 instructions to move "true" or "false" into a variable. I'm afraid not. People would have noticed that major design flaw by now.

You also have to get out of your head the idea that your switch isn't bouncing. It will bounce. Maybe after 20 seconds it has stopped bouncing but that isn't the same as saying "they are not bouncing".



Ok... they are bouncing buy 20 seconds later, when it matters, they are not.

freakdaddy



They are not bouncing.  As I said before.  Once they are pressed it is 20 seconds before the code is question gets executed again.  At that point (which is 20 seconds approx) deployPressed and armDown are both still true but they should not be.


Yes you are right.  It *must* be a bug in the Arduino.  Nearly 1 million have shipped and you're the first person to stumble across the "takes 20ms to read a switch" bug.

-or-

Something is happening with your hardware you don't fully understand.

Which is the most likely?

1.  Now on the 3rd page, nothing new has been posted since the first couple of posts.
2.  Your only claim that no bouncing is occurring is that Serial.print() says so.  Well, Serial.print() is effectively a de-bounce delay.
3.  Two people (myself included) have suggest a hardware method to prove if it is bouncing or not (hint: capacitors.)
4.  Your description of the issue is absolutely consistant with a hardware issue:  e.g. bouncing 
5.  The inconsistency in your code and your descriptions is making it exceptionally difficult to follow.  "When the button is pressed and the pin is high and the variable is false, I see something 20 seconds later." 

Your code would be easier to follow if
a) you used constants to define your pin numbers.  digitalRead(6) means nothing to anyone except the avr-gcc compiler.
b) you stuck to "high" or "true" along with their negative counterpart "low" or "false."  Don't mix between the two.  Sure the compiler sees them as the same thing, but it makes it difficult for dumb humans to follow, especially if you dont:
c)  Consistently refer to your buttons as "pressed" or "high".  Don't go mixing pressed/unpressed/high/low especially when you are inverting inputs with pull-ups.  I can't tell what you mean by "high" in the random context you use it.



What I am having a very hard time with is getting you guys to realize is that the switch is not being pressed when I see this problem.  Therefore there is no bounce.  The switch is pressed 20 seconds ago.  Then I sit back and wait.  Then I observe a variable not change.  Look at the code and my description.  No change in the state of a switch = no bounce!!!!!!

freakdaddy



2.  Your only claim that no bouncing is occurring is that Serial.print() says so.  Well, Serial.print() is effectively a de-bounce delay.




My claim is that the variables armDown and deployPressed are not reflecting the status of the respective pin.  A pin that is connected to a switch that has not been pressed since 20-30 seconds ago.

nickgammon


Then I sit back and wait.  Then I observe a variable not change.


You are not observing any variables as you are not a piece of electronics wired into the processor.

You are observing behaviour of attached things from which you are making deductions. As we said before - how many times? - the simple act of putting in a serial print is likely to slow things down so much that the switch will have stopped bouncing. Therefore you "observe" no bounce.

I'm losing a little interest in your insistence that a switch stops bouncing after 20 seconds. Obviously. It stop bouncing after 20 milliseconds. We are trying to help solve your problem here without a lot of help. Circuits. Descriptions about what switch is attached where. A photo maybe.

Here's one theory, in the complete absence of any detailed description of your setup:

You press a switch, the motor starts, the power drawn resets the Arduino, the variables are now in a different state to what you think they are. So your assertion that something "can't happen" would indeed happen if there is a reset. This might happen due to the current drawn (motor startup, for example) or a spike from a noisy motor.

Quote

My claim is that the variables armDown and deployPressed are not reflecting the status of the respective pin.  A pin that is connected to a switch that has not been pressed since 20-30 seconds ago.


Circuit please.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

freakdaddy

I'll draw you a picture and post it.  But really.  All it is is 4 microswitches, normally open, one leg on a pin, the other on ground.  Then a relay board connect to 5v and ground and a single pin to the input.  I would know if the board resets because I have a serial.print("Ready") in the setup.

nickgammon

Not in the version you posted you don't.


Code: [Select]

...

void setup() {                
 //switches
 pinMode(9, INPUT);  // arm down
 digitalWrite(9, HIGH);
 pinMode(7, INPUT);  // arm up
 digitalWrite(7, HIGH);
 pinMode(6, INPUT);  // deploy
 digitalWrite(6, HIGH);
 pinMode(5, INPUT);  // retract
 digitalWrite(5, HIGH);

 //motors
 pinMode(8,OUTPUT); // arm motor
 digitalWrite(8, HIGH);  
}
...
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

freakdaddy


Not in the version you posted you don't.


That is correct.  I stripped out all the serial code to simplify it for posting. 

jfhaugh

Did you add some de-bounce caps while you were in there stripping out code?

Send your mailing address -- I'll drop a couple of 0.1uF ceramic caps in the mail.  Your code will likely still be broken by the time the caps show up ...

freakdaddy

You know...  I respect the fact that a lot of you guys are more experienced than I am with the arduino.  But for the life of me I cannot understand why almost every one of you who have responded to this thread insist that this has something to do with switches bouncing.  Read the code and the description of the problem.  When this problem shows itself, a variable that was set a long time ago has the wrong value.  It has nothing to do with a switch.  You have to go back to the original code I posted and read and understand what it is doing regardless how poor of a job you think I did.  Then understand that from the time that the motor starts (from deployPressed) till when it stops, 20-30 seconds has passed.  Sure the switch may have very well bounced back when I started but it DOES NOT MATTER because the way I wrote the code and the FACT that the motor runs for 20-30 seconds takes care of any bounce.  The variable deployPressed is still true 20-30 seconds after is was pressed.  That is the problem.  And yes I will post the circuit that shows the 4 switches connected to the arduino.  I have to get my scanner hooked back up.

nickgammon


But for the life of me I cannot understand why almost every one of you who have responded to this thread insist that this has something to do with switches bouncing.  Read the code and the description of the problem. 


What I don't understand is why you think you have found a bug in either the Arduino (300,000+ units sold) or the Atmega328 chips (presumably somewhat more sold) when you have a circuit, and code where, a problem which occurs directly after a switch is pressed is solved by adding a 20 mS delay, when typically a 20 mS delay would debounce a switch.

You don't know what the variables have in them, or when their values change, without putting in debug code, the debug code itself which would debounce the switch.

My questions have gone unanswered about:


  • Your exact circuit

  • Which switch is at which end (which end is "up"?, which end is "deployed"?)



Let me put it like this ... what is your hypothesis about the nature of the problem, assuming that it is not a switch bounce? Faulty Arduino? Library error? Compiler error? Atmega328 design fault?

Also under questioning you admit you haven't actually posted the code you are using:

Quote
I stripped out all the serial code to simplify it for posting.


So you are asking us to debug "simplified" code. The simplification could be the problem. Give us a bit of a break here.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

Go Up