Commented Code has Adverse Effects

Projects Programming
1

I have programmed for a long time and this is a first for me. I have read other posts where OP was usually using a function incorrectly. However, they resolved theirs and I can't figure out why mine is also doing the same. The following code works flawlessly if the 2 beginning/ending debug statements are uncommented. If they are commented, it's like the program never goes into the loop(). Completely boggled and was hoping someone could help me out. Maybe I should stick to Unity games haha. Appreciate any feedback.

Sensor at the moment is a break-sensor which wired correctly to the pin 2 and LED has resistor, etc. So I don't believe it's the wiring.

#define SENSOR_PIN_1 2
#define SIGNAL_LED_PIN 12

#define LED_PERIOD 1000

static bool sensorTripped = false;

void setup() 
{
	Serial.begin(128000);

	// enable sensor 1's signal pin
	pinMode(SENSOR_PIN_1, INPUT);			

	// set led pin
	pinMode(SIGNAL_LED_PIN, OUTPUT);

	Serial.println("Setup!");
}


void loop() 
{
	//Serial.println("-- Arduino now at top of main loop. --");

	sensorTripped	= ( digitalRead(SENSOR_PIN_1) == HIGH );

	// if sensor is tripped, signal alert.
	if (sensorTripped)
	{
		Serial.println("Sensor 1 tripped!");
		digitalWrite(SIGNAL_LED_PIN, HIGH);
		delay(LED_PERIOD);
	}
	else
	{
		digitalWrite(SIGNAL_LED_PIN, LOW);
	}

	//Serial.println("Arduino now at bottom of main loop.\r\n");
}
2

I am not sure what you mean.

SENSOR_PIN_1 and SIGNAL_LED_PIN are required for the sketch to work.
If you comment them out, then your code doesn't compile.

http://www.cplusplus.com/doc/tutorial/preprocessor/

3

I had to change the baud rate to 115200 to test with the serial monitor, but aside from that your code works fine for me, both with and without the serial debug lines.
This is what the serial monitor shows with those lines commented out:-

Setup!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!
Sensor 1 tripped!

And this is what I get if I don't comment them out:-

Setup!
-- Arduino now at top of main loop. --
Sensor 1 tripped!
Arduino now at bottom of main loop.

-- Arduino now at top of main loop. --
Arduino now at bottom of main loop.

-- Arduino now at top of main loop. --
Arduino now at bottom of main loop.

-- Arduino now at top of main loop. --
Sensor 1 tripped!

(Pin 2, (SENSOR_PIN_1), is floating in my tests - I have nothing connected to it.)

Edit: @ieee488, I think you mis-read the opening post.

4

Wha is this doing?
sensorTripped = ( digitalRead(SENSOR_PIN_1) == HIGH );

5

How is the sensor wired?

When the sensor is triggered... you say it's a break sensor, and I see that triggered is high, but you're not using the built-in pull up. Are you using an external one? If not, the pin is floating and can take on random value from ambient electromagnetic fields. The TX pin right next to pin 2 might be producing enough noise on that pin to change behavior.

6

LarryD:
Wha is this doing?
sensorTripped = ( digitalRead(SENSOR_PIN_1) == HIGH );

Comparing the value read from the pin to HIGH and then assigning true or false to sensorTripped. Isn't that obvious?

7

LarryD:
Wha is this doing?
sensorTripped = ( digitalRead(SENSOR_PIN_1) == HIGH );

I was just about to edit and suggest that he only needs:-

sensorTripped = digitalRead(SENSOR_PIN_1);
8

The following code works flawlessly if the 2 beginning/ending debug statements are uncommented. If they are commented, it's like the program never goes into the loop()

I can not confirm that. The code runs for me (with changed baud rate) when I switch pin 2 between 5v and ground.

9

Isn't that obvious?

Not after a glass of wine.
Better IMO

if (digitalRead(SENSOR_PIN_1) == HIGH)
{
10

LarryD:
Not after a glass of wine.
Better IMO

if (digitalRead(SENSOR_PIN_1) == HIGH)

{

sensorTripped   = ( digitalRead(SENSOR_PIN_1) == HIGH );

Is just an overly explicit way of doing the exact same thing you are suggesting. Just because it isn't your way doesn't mean it isn't right. And when has caching a variable ever been harmful?

DrAzzy:
How is the sensor wired?

When the sensor is triggered... you say it's a break sensor, and I see that triggered is high, but you're not using the built-in pull up. Are you using an external one? If not, the pin is floating and can take on random value from ambient electromagnetic fields. The TX pin right next to pin 2 might be producing enough noise on that pin to change behavior.

The pin is grounded via pulldown resistor 10K. I understand this concept and definitely doesn't seem to be the culprit. I can disconnect the break sensor and use + and still get same result as OP. For some reason, with the debug statements enabled cause it to run perfectly every time, and when they are commented out, I get no message, whatsoever. It's bizarre.

OldSteve:
I had to change the baud rate to 115200 to test with the serial monitor, but aside from that your code works fine for me, both with and without the serial debug lines...

This is what I would expect, for it just doesn't work with them uncommented. I have tried 2 different UNOs.

Pin 2----------------------------- R1(10k) ---------Ground
|
|___________ break sensor signal

This stuff should be elementary, no? But for some reason just doesn't produce what is expected. I have had the same problem before, so I started over from scratch to be a bit more thorough IE verbose statements.

11

Is just an overly explicit way of doing the exact same thing you are suggesting

Why make things less clear for absolutely no reason? What is the benefit?

Iowaska:
.....for it just doesn't work with them uncommented. I have tried 2 different UNOs.

But as I said, it does work with those lines uncommented. I tested it and showed the results from the serial monitor. I'm using a UNO, IDE V1.6.5.

12

This is what I would expect, for it just doesn't work with them uncommented.

The code runs for me with the lines commented out or printing. I have a clean switch on pin2 from 5v to ground.

13

Just because it isn't your way doesn't mean it isn't right. And when has caching a variable ever been harmful?

who said it isn't right or it's wrong?
who said caching a variable was harmful?

So much for:

Appreciate any feedback.

14

For some reason, with the debug statements enabled cause it to run perfectly every time, and when they are commented out, I get no message, whatsoever.

....for it just doesn't work with them uncommented. I have tried 2 different UNOs.

I think you need to make up your mind.

15

What is this sensor you are using? Link please.

16

OldSteve:
I think you need to make up your mind.

The point here is that debug statements and comments shouldn't effect code. If a system is that brittle, it's for the birds.

LarryD:
What is this sensor you are using? Link please.

I mean, the sensor doesn't seem to be the issue. I have tried a button, PIR, break sensor, and straight +. All work as desired with statements enabled. Commented, nothing works.

LarryD:
who said it isn't right or it's wrong?
who said caching a variable was harmful?

So much for:

Post was edited prior to your comment...

17

If you disconnect the sensor and use:

pinMode(SENSOR_PIN_1, INPUT_PULLUP);

What happens?

18

Iowaska:
The point here is that debug statements and comments shouldn't effect code. If a system is that brittle, it's for the birds.

Well as far as I can see from my testing of your code, the debug statements don't affect the code or it's execution at all, except in the way you intended. Everything works fine for both cattledog's tests and mine, with or without the serial print lines and regardless of the state of the sensor input pin.

I don't know what more to say, so I'll leave it to you and others to hopefully sort out.

19

Assumption, is your sensor is wired similar to S3

20

LarryD:
If you disconnect the sensor and use:

pinMode(SENSOR_PIN_1, INPUT_PULLUP);

What happens?

No LED with either statements en/disabled. And also tried with DigitalWrite(SENSOR_PIN_1, INPUT_PULLUP);

LarryD:
Assumption, is your sensor is wired similar to S3

S3 is exactly how I have it wired, yes.