Go Down

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

mrdovey

I honestly don't know, but if you're certain it isn't you the first board listed on the forum index page is listed as being for Arduino problems. Give it a try.

mromani


[...]I do think there is an arduino bug here however.


Ok. What I'd do first is try to describe the bug. Then I'd try to write a test sketch that would show the problem.
Sometimes the simple act of trying to explain what you expect from your code and what you get instead makes you understand where the problem (and the solution) lies.
(hint: 99% of times it's not in the platform).


Is there an issue reporting system in place for arduino?


I think you're right into it :-)

jfhaugh



[...]I do think there is an arduino bug here however.


Ok. What I'd do first is try to describe the bug. Then I'd try to write a test sketch that would show the problem.
Sometimes the simple act of trying to explain what you expect from your code and what you get instead makes you understand where the problem (and the solution) lies.
(hint: 99% of times it's not in the platform).


Is there an issue reporting system in place for arduino?


I think you're right into it :-)


If I read the problem description correctly, this really does sound like a =hardware= problem.  Not with switch bounce, but possibly with something happening when the motor is operating and/or stopped.  Liberal application of capacitors across =all= switches, as well as a beefier cap across the power supply, might help.

For a test, I'd suggest disconnecting the motor, then pressing the various buttons by hand.  And I'd still add the caps.  Starving children in China need us to buy more capacitors ...

nickgammon


Yet somehow deployPressed and armDown are still true 20 seconds later even though the pins are false. 


Quote
Code: [Select]
armDown=!digitalRead(9);
  armUp=!digitalRead(7);
  deployPressed=!digitalRead(6);
  retractPressed=!digitalRead(5);


You mean "even though the pins are true" I hope, since you are doing "not" what the pins read.

Pins are not true or false, they are HIGH or LOW. Let's get the terminology straight.

Can you describe the hardware a bit more? Which end is the armUp button? Before you start submitting bug reports about the Arduino, better get straight what is happening. If you swapped the armUp and armDown tests (ie. the switches are mis-wired) this might account for some of what you see.

I recall another thread not that long ago where I suggested a wiring error. "Absolutely not!" the poster declared. "Photo?" I replied. About 4 or 5 pages in (I'm not kidding) there was an "oops, I made a wiring mistake".
Please post technical questions on the forum, not by personal message. Thanks!

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

freakdaddy

#19
Feb 16, 2012, 10:12 pm Last Edit: Feb 16, 2012, 10:47 pm by freakdaddy Reason: 1


Yet somehow deployPressed and armDown are still true 20 seconds later even though the pins are false.


Quote
Code: [Select]
armDown=!digitalRead(9);
  armUp=!digitalRead(7);
  deployPressed=!digitalRead(6);
  retractPressed=!digitalRead(5);


You mean "even though the pins are true" I hope, since you are doing "not" what the pins read.

Pins are not true or false, they are HIGH or LOW. Let's get the terminology straight.

Can you describe the hardware a bit more? Which end is the armUp button? Before you start submitting bug reports about the Arduino, better get straight what is happening. If you swapped the armUp and armDown tests (ie. the switches are mis-wired) this might account for some of what you see.

I recall another thread not that long ago where I suggested a wiring error. "Absolutely not!" the poster declared. "Photo?" I replied. About 4 or 5 pages in (I'm not kidding) there was an "oops, I made a wiring mistake".


{Had to edit...  Sorry I posted before I was done typing!!!!]

I will certainly run more tests before submitting a bug.  What bothers me is this...  I inserted all kinds of serial.print statements to see what was happening.    I even put one in the main loops to watch it the whole time to see if I could see bounces.  Here is what happened...
(pseudo code)
Code: [Select]

SerialA.print(!digitalRead(6), deploying,!digitalRead(9), retracting)
if (deployPressed && !deploying && armDown && !retracting) {
    SerialB.print(deployPressed, deploying, armDown, retracting)
    deploying=true;
}

1. System idle
1.5. SerialA.print is repeating 0 0 1 0
2. Press deployPressed button.
2.5 SerialA.print shows 1 0 1 0
3. serialB.print shows 1 0 1 0
4. now because deploying=false the code above will never execute again for the time being.  It takes around 20 seconds to fully extend the arm.
4.5 SerialA.print is repeating 0 1 0 0 <- You would think that deployPressed and armDown would be false as well
5. arm is done deploying and code elsewhere sets deploying=false.
7. SerialA.print shows 0 0 0 0
6. code above executes again because deploying is now false AND deployPressed and armDown are STILL TRUE.  Remember that deployPressed and armDown were last touched 20 seconds ago.
7 serialB.print shows 1 0 1 0 <- should not be


nickgammon

Yes, well debugging changes behaviour.

Say you did serial prints at 9600 baud. Each character (being 10 bits) will take 1/960, that is 1 mS to send. So if you send "System idle" you have, in effect, added about a 12 mS delay. So you won't see bounces.

You need to hook up something with a faster response time like a digital scope or logic analyzer and monitor what is happening.

Quote
Code: [Select]
System idle
Press deployPressed button.
serial.print show


Huh?
Please post technical questions on the forum, not by personal message. Thanks!

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

mrdovey

Improving visibility...
None of the debug output should interfere with any of the process.
Code: [Select]
void setup(void)
{  Serial.begin(9600);
   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);
   pinMode(8,OUTPUT);                   // arm motor
   digitalWrite(8, HIGH); 
}

void loop(void)
{  Serial.println("Awaiting deploy button *** top of cycle ***");
   while (digitalRead(6)) ;            /* Wait for deploy button              */
   Serial.println("Deploy button pressed, turning motor on");
   digitalWrite(8,LOW);                /* Arm motor on                        */
   while (digitalRead(7)) ;            /* Wait for extended limit switch      */
   digitalWrite(8,HIGH);               /* Arm motor off                       */
   Serial.println("Found extended limit switch, stopped motor");
   Serial.println("Awaiting retract button");
   while (digitalRead(5)) ;            /* Wait for retract button             */
   Serial.println("Retract button pressed, turning motor on");
   digitalWrite(8,LOW);                /* Arm motor on                        */
   while (digitalRead(9)) ;            /* Wait for retracted limit switch     */
   digitalWrite(8,HIGH);               /* Arm motor off                       */
   Serial.println("Found retracted limit switch, stopped motor");
}

I'm beginning to wish I had the hardware to duplicate your test setup.  :)

freakdaddy


Yes, well debugging changes behaviour.

Say you did serial prints at 9600 baud. Each character (being 10 bits) will take 1/960, that is 1 mS to send. So if you send "System idle" you have, in effect, added about a 12 mS delay. So you won't see bounces.

You need to hook up something with a faster response time like a digital scope or logic analyzer and monitor what is happening.

Quote
Code: [Select]
System idle
Press deployPressed button.
serial.print show


Huh?



Sorry Nick I accidentally hit submit before I was done typing.  I fixed it.  Reread the post above your Huh? response for my full post.

freakdaddy



I'm beginning to wish I had the hardware to duplicate your test setup.  :)


It's just an smd uno with 4 microswitches tied to ground and an external relay board.

mrdovey

<grin> Thats four microswitches and a relay board more than what I have here.

freakdaddy


Yes, well debugging changes behaviour.

Say you did serial prints at 9600 baud. Each character (being 10 bits) will take 1/960, that is 1 mS to send. So if you send "System idle" you have, in effect, added about a 12 mS delay. So you won't see bounces.

You need to hook up something with a faster response time like a digital scope or logic analyzer and monitor what is happening.


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.

freakdaddy


<grin> Thats four microswitches and a relay board more than what I have here.


I don't think the relay board is relevant and you could simulate switches by tapping jumpers together.  That's if you have the uno. :)

jfhaugh

DO YOU OWN ANY CAPACITORS?

I have bags of them.  I'll mail you a couple if you can't find any where you live.

Put some capacitors across the digital input pins and ground.  You might also want to add flyback diodes and capacitors across the relay coils.  This "bug" has all the symptoms of being a hardware problem, including the fact that the problem disappears when you add timing delays with the print statements.

mrdovey

I've already tested my poor Arduino almost to death. I've been wondering if your outboard hardware is producing power spikes that provoke circuit gremlins.

nickgammon


4. now because deploying=false the code above will never execute again for the time being.  It takes around 20 seconds to fully extend the arm.


You mean "because deploying == true".

I'm slowly going insane looking at this code. You are displaying what you have "not" read.

Quote
Code: [Select]
SerialA.print(!digitalRead(6), deploying,!digitalRead(9), retracting)


How about putting some symbolic constants in? And displaying what you get and not negating it? You are confusing yourself even, as you can see.

And make the debugging easier to read. And why SerialA and SerialB?

Like this:

Code: [Select]
Serial.print("Deploy button = ", digitalRead (DEPLOY_BUTTON),
             ", deploying variable = ", deploying,
             ", Arm down switch = ", digitalRead (ARM_DOWN_SWITCH),
             ", retracting variable ", retracting)


And answer my question:

Quote
Can you describe the hardware a bit more? Which end is the armUp button?





Quote
They are not bouncing.  As I said before.


What do you mean "they are not bouncing"? Have you get special switches that don't bounce? Have you measured their output with a scope and seen no bounces? Because my switches typically bounce about 20 times.

Quote
It's just an smd uno with 4 microswitches tied to ground and an external relay board.


You mean, one end is connected to the pins, and the other ones to ground?

How is this relay board connected? Come on, time for a wiring diagram.
Please post technical questions on the forum, not by personal message. Thanks!

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

Go Up