Is there a way to limit the time of a current output pin state?

I have the if statement below that will turn pin10 to high when a condition is true. In this case sensorValue < 10
the sketch will keep pin 10 on for as long at the condition is true. What I would like to do is code some sort of time limit for which pin 10 can be HIGH. In other words I want to set pin 10 to high for a maximum time of 1 minute regardless in the event the if condition is true for longer than 1 minute. The goal of this is to not damage a component being actuated by pin 10. Think of this as a failsafe.

I googled a bit but nothing came back with anything close enough for me to understand.
see the standard code below.

int sensorValue = 0
int sensor1 = A0

Void Setup () 
{pinMode (pin10, OUTPUT);}

void Lop ( ) {
analogRead(sensor1);
if (sensor1 < 10)
  {
    digitalWrite(pin10, HIGH);
  }
else
  {
    digitalWrite(pin10, LOW);
}

Count the time (millis) that has passed since it went high. Change the if value to include || (OR) and change to low if state changes, OR time has lapsed.

Check the BlinkWithoutDelay sketch for millis example.

Look at the attached sketch for an example .

garagesensor.ino (2.45 KB)

crullier:

int sensorValue = 0

int pin10 = 10

pinMode (pin, OUTPUT);

Void loop( ) {
if (sensorValue < 10)
  {
    digitalWrite(pin10, HIGH);
  }
else
  {
    digitalWrite(pin10, LOW);
}

Does sensorValue magically get a vallue assigned to it?
pin10 is an input. Why do you expect it to be an output?
That code won’t compile.
Perhaps they can help you at http://snippets-r-us.com/

Does sensorValue magically get a vallue assigned to it?

ha ha ha.. (that's one way to say you forgot to do an analog read....)

haha you guys are so "cruel" =) I made a mistake on the coding but yes "magically" I get an alternating sensor value for my expression.

in the code you shared:

The variable blpinstatus checks for the state of the output and run the timer. great I will look at more example if milli( )

This morning when I woke up I was thinking that just like in your example, the times had to be actuated by the state of the pin. I am glad I am starting to think in terms of how the hardware and code need to work even if I do not know the syntax.

If you ask yourself a question before you go to sleep, you will wake up with the answer…

interesting how that works eh?

That's called background process programming ( I just made that up... XD)

What this shows is that it's best to capture the required process somehow, before going anywhere near the IDE and typing a load of code in. Various approaches to diagramming exist for that very purpose: old-school traditional flowcharts, structure charts, state diagrams and so on.

Or, as you say, sleep on it.... problem with that is (for me anyway) is that if I wake up in the middle of the night with a light-bulb moment the light-bulb goes out immediately and in the morning the idea has seeped away.

I used to troubleshoot microprocessors for hospital bedside patient monitors (the kind you see in every hospital room scene in a movie. The funny thing is that "General Hospital " TV series preferred using our monitors even though they didn't actually have any real patients. Anyway, I worked on thousands of them and there were always ones you couldn't get working right away and it would drive you nuts until you just put it out of your mind and went on to something else and then one day you would wake up in the middle of the night with that light bulb moment blurting something about C15 or R10 or U3 and when you got to work and tried it , half the time it was correct. But only half the time. I'll take 50% of impossible any day...(the go in the bone pile if they can't be fixed . Once they're there they are considered "impossible to fix")

raschemmel:

Does sensorValue magically get a vallue assigned to it?

ha ha ha.. (that's one way to say you forgot to do an analog read....)

Of a digital pin...

PaulS:

raschemmel:

Does sensorValue magically get a vallue assigned to it?

ha ha ha…
(that’s one way to say you forgot to do an analog read…)

Of a digital pin…

LOL, it was late on a week night :cold_sweat: I should go edit that post.

Does having "Serial.println ()" lines in the code to print analogRead values slow down the code in anyway?

I am asking this because I was using the serial monitor to look at value ranges for my code. In order to able to read the number I had added delay. (delay (600;)).

Well I noticed that as long as I left that delay there the rest of the code would not work well. Basically the IF statements that following the reading of the sensors were not consistent. Thorough looking at milli() I learned the delay halts the code execution until the time expires. So I removed that lone and the code works. So then I wonder if having the Serial.println lines affect the code below it in anyway.

it is almost as if in reality you do not want to use delay () at all.

analogRead(Sensor1);
Serial.println(Sensor1);
Serial.println ();   // I want a blank line, not sure how else to do this.
delay (600);  // gives me time to read the code on screen.

Does having "Serial.println ()" lines in the code to print analogRead values slow down the code in anyway?

Of course it does. How can you imagine that it wouldn't?

PaulS:

Does having "Serial.println ()" lines in the code to print analogRead values slow down the code in anyway?

Of course it does. How can you imagine that it wouldn't?

well, I don't know as much as you guys do (I am sure it evident in my posts) and I can only asume - therefore I ask and I trust your answers. you know what happens when you assume right?

I guess the point I am gathering from this is that every lines has the potential to slow down the code the time it takes to read such line and execute it, even if its milliseconds. So you want to keep code a "light" as possible.

again I am not a programmer, I am just a wanna be. :)

I guess the point I am gathering from this is that every lines has the potential to slow down the code the time it takes to read such line and execute it, even if its milliseconds

Yes, every statement takes some amount of time to execute.