How to undo a flipped state?

Projects Programming
1

So, on advice from someone here I created a code that flipped the perceived state of an LED with this code

LED_05_state = !LED_05_state

The problem is sometimes in a different part of the code I need the LED to be an absolute state. So, when I say

( digitalWrite (LED_05, LED_05_state) )

I get the LED output that might be high, and might be low. And that's what I want for that part of the code.

But when I want to wrote the LED low,

( digitalWrite (LED_05, LOW) )

it appears to write the LED to the opposite of whatever state it was last in.

I tried creating a different LED state "LED_05_stateB" as a constant integer of LOW and then writing the code

( digitalWrite (LED_05, LED_05_stateB) )

But that still leaves the LED in the opposite of the state it was in.

Any quick way to undo the flipped LED state?

2

it appears to write the LED to the opposite of whatever state it was last in.

No that code will ALWAYS set the pin low. So if it does flip the state then it was high to begin with.

3

Grumpy_Mike:

it appears to write the LED to the opposite of whatever state it was last in.

No that code will ALWAYS set the pin low. So if it does flip the state then it was high to begin with.

See? And that's what I thought it should be but it's not working that way.

I have the following code in the lowest level of the loop

  if ( ( digitalRead (BTN_01 == LOW)) && ( digitalRead (BTN_05 == LOW) ) )
  {
    digitalWrite (LED_05, LOW);
    digitalWrite (LED_06, LOW);
    digitalWrite (LED_09, LOW);
    digitalWrite (LED_10, LOW);
  }

But the state never is left in a LOW position unless that's how the previous code left it.

4

It appears I might have conflicting code.

Why do I say this? I just realized that the LED's in question are dimmer than normal when they are out of whack but normal intensity when they are deliberately activated. This leads me to believe that, as the processor runs through the loop it's toggling the relay rapidly. Low to high.

But, still, undoing the state of the LED would be preferred.

5

Have you tried asking your question at snippets-r-us?

the LED's in question are dimmer than normal when they are out of whack but normal intensity when they are deliberately activated.

Whatever that means.

6

AWOL:
Have you tried asking your question at snippets-r-us?

Whatever, Richard!

7

It would help us to help you if you post all your code. Many problems are caused by code outside of the immediate location of the snippet of code that are posted, as you have possibly found. Without the whole context of your code, you will not get the full benefit of people's help.

8

marco_c:
It would help us to help you if you post all your code. Many problems are caused by code outside of the immediate location of the snippet of code that are posted, as you have possibly found. Without the whole context of your code, you will not get the full benefit of people's help.

Yeah, I suppose I could post all 1609 lines of my code here for all to see, just to get a simple answer to a simple question that, apparently has no answer.

I'm not asking anyone to validate or scrutinize my code. I'm simply asking if there's an "undo" code for !LEDstate (the flip state of LEDstate).

If not then it's just that I have my code in the wrong places because setting LED_* to LOW isn't solving the issue.

9

I'm simply asking if there's an "undo" code for !LEDstate (the flip state of LEDstate).

I have no idea what that means, but I would be inclined to put a Serial.print in here to see if it's actually getting to this part:

if ( ( digitalRead (BTN_01 == LOW)) && ( digitalRead (BTN_05 == LOW) ) )
  {
       Serial.println("BOO!");
    digitalWrite (LED_05, LOW);
    digitalWrite (LED_06, LOW);
    digitalWrite (LED_09, LOW);
    digitalWrite (LED_10, LOW);
  }

As pointed out above, setting something LOW sets it LOW regardless of previous condition. So either the code isn't coming here and something else is setting it, or it does come here and something else in your logic sets it back again too quickly for you to see.

10

JimboZA:
As pointed out above, setting something LOW sets it LOW regardless of previous condition. So either the code isn't coming here and something else is setting it, or it does come here and something else in your logic sets it back again too quickly for you to see.

And that red part is what I was saying above when I said the LED was "dim". I thin my code is conflicting with itself.
When the code loops it basically is saying "turn LED ON" at one point in the code and "turn LED OFF" in another part. So basically as it loops it's modulating.

But, as I suspected, and is now verified, if I set it to LOW, it's LOW!

now I just have to stare at code long enough to find out why it's going back high...

11

now I just have to stare at code long enough to find out why it's going back high...

Yeah, that's going to work...

What you really need to do, is draw up a sheet with all the variables along the top, and walk through every step of code filling in the current value of each on a new line. then when you get to a branch in the code, perform the branch according to the values of the variables the logic looks at.

Rinse and repeat....

12

Yeah, but we each have a process we use that works for us.

I think my problem lies here in this code snippet.

if (( digitalRead (BTN_01 == LOW)) && ( digitalRead (BTN_05 == LOW) ))

Doesn't this say that both conditions must be true for the code below it to execute?

13

Do you intend:

digitalRead( BTN_01 == LOW )

or

digitalRead( BTN_01 ) == LOW

They are very different.

14

That's why I suggested the Serial.print to see if the logic actually ever took you there...

EDIT.... I was also starting to wonder about all the brackets

15

JimboZA:
That's why I suggested the Serial.print to see if the logic actually ever took you there...

EDIT.... I was also starting to wonder about all the brackets

Adding a serial print tutorial to my noggin just isn't a good idea at the moment. It would take me time and brain power and probably add confusion at this point.

Someday, soon, I will be ready to tackle that one and look back and see all the time I was wasting. But today isn't the day.

So, all those brackets? Elaborate, please.

16

Referring to my previous post ( How to undo a flipped state? - #13 by pYro_65 - Programming Questions - Arduino Forum )

digitalRead( BTN_01 == LOW )

I do not think this is what you want.

I'm pretty sure you want to: Read the value of BTN_01 and compare it to the value LOW.

To achieve this you need to put the comparison on the outside of the function call, otherwise you only read pin 0 or 1*, not BTN_01 or BTN_05 due to the way boolean values translate to integers.

digitalRead( BTN_01 ) == LOW
  • True values are anything other than zero, so it may not be 1, and could be regarded as possibly random.
17

see all the time I was wasting. But today isn't the day.

So, all those brackets? Elaborate, please.

No, that would be time I'm wasting and today isn't the day.

Edit.... but I see pYro has explained anyway.

Have you never used Serial print before?- fundamental debugging tool.

Put Serial.begin(9600); in setup(), then add the Serial.println("Boo"); line I suggested... upload the code, start the IDE monitor with ctl+shift+m and do whatever you expect takes you to that point. See if the monitor prints "boo". If not the logic didn't work....

18

JimboZA:

see all the time I was wasting. But today isn't the day.

So, all those brackets? Elaborate, please.

No, that would be time I'm wasting and today isn't the day.

Edit.... but I see pYro has explained anyway.

Have you never used Serial print before?- fundamental debugging tool.

Put Serial.begin(9600); in setup(), then add the Serial.println("Boo"); line I suggested... upload the code, start the IDE monitor with ctl+shift+m and do whatever you expect takes you to that point. See if the monitor prints "boo". If not the logic didn't work....

Thanks.
I had a feeling you knew what was hanging me up but were just not willing to point it out.

19

Bittsen:
I had a feeling you knew what was hanging me up but were just not willing to point it out.

Not true.

I suggested the debug prints early on, since it seemed possible or even likely that the flow wan't actually going there, for whatever reason. I did point that out, that was a hunch, more than anything.

Then it struck me that the brackets looked wrong round about the time someone else did. I was however reluctant to waste my further time when you thought that implementing my previous suggestion was wasting yours. But as it happens the bracket thing was being explained in another post at the same time.

Waste your time by all means- just don't waste mine.

20

OK, so just adding "Serial.begin(9600);" to the setup screwed up the function of the whole sketch.
Adding the Serial.println("Boo"); screwed things up even more.

The code compiles correctly but when I run it on the Arduino it has a ton of unfavorable results.