Go Down

Topic: Seeking better testing language (Read 1 time)previous topic - next topic

myggle

#15
Jun 10, 2015, 02:41 pmLast Edit: Jun 10, 2015, 02:42 pm by myggle
Code: [Select]
`  if (now.hour() >= 6 && now.minute() >= 0) {  // Turn on time for Veg Lights, ON at 6am    digitalWrite(Relay_A, TURN_ON);    Serial.print("\t");    Serial.println(F("Vegetative Lights On"));  //  Text printed to serial monitor    Serial.print("\t");  }  else if (now.hour() >= 0 && now.minute() >= 0) // "else if" was needed to create opposition to lights on  {  // Turn off time for Veg Lights, OFF at 12am    digitalWrite(Relay_A, TURN_OFF);    Serial.print("\t");    Serial.println(F("Vegitative Lights OFf"));  //  Text printed to serial monitor    Serial.print("\t");  }`
Can you envision a scenario where the hour value is 6 or more, and the minute value is not greater than or equal to 0?

Hours count from 0-23, minutes 0-59.  So if hours are 6-23 and minutes are 0-59, the tests becomes true and Relay_A is HIGH

Can you envision a scenario where the else if test would not evaluate to true?

If for example the now.hour is 3, this else test is false as the now.hour is outside of the true state as depicted above.
The test for Relay_A does work flawlessly, but it will only be tested true once every 24 hours and for a duration of 18 hours.  Relay_B will test true no less than twice daily, for the 10 minute period I desire.  Initially I wanted for individualized text outputs on the serial monitor which then justified the need to break up the 24 hour time span for Relay_B into multiple tests that needed to be true in themselve only and false during other tests which further made for more complicated code I'm sure.

Now with using jurs scheme of using the boolean tests and my decision to change the output language to a one phrase fits all, the code no longer needs to reflect individualized blocks for individualized events.  This all of course is predicated that I can find why Relay_B is only pulsing when it should be constant HIGH like that of Relay_A.

PaulS

#16
Jun 10, 2015, 02:46 pm
Quote
This all of course is predicated that I can find why Relay_B is only pulsing when it should be constant HIGH like that of Relay_A.
Do the pulses match the serial output? If not, you have a hardware problem that no amount of software tweaking is going to fix.

myggle

#17
Jun 10, 2015, 03:45 pm
Do the pulses match the serial output? If not, you have a hardware problem that no amount of software tweaking is going to fix.
I don't know what serial output is but the serial monitor shows the text with every iteration of the loop, the same as it does for the Relay_A condition which is true 75% of the time.  I just tested the hardware with this sketch;
Code: [Select]
`void setup() {  // initialize digital pin 13 as an output.  pinMode(30, OUTPUT);  pinMode(31, OUTPUT);}// the loop function runs over and over again forevervoid loop() {  digitalWrite(30, HIGH);   // turn the LED on (HIGH is the voltage level)  digitalWrite(31, HIGH);  delay(1000);              // wait for a second  digitalWrite(30, LOW);    // turn the LED off by making the voltage LOW  digitalWrite(31, LOW);  delay(3000);              // wait for a second}`
... and it resulted in the relays turning on the test lights for 3 seconds and off for 1 second as expected, so it has to be code?

PaulS

#18
Jun 10, 2015, 04:02 pm
Quote
I don't know what serial output is but the serial monitor shows
The Serial Monitor is an application that runs on the PC. It displays serial data that the Arduino output.

Since the simple sketch works, add to it.

Put all the code for printing the time to the serial port in a function. Call that function from loop(). Do NOT clutter up loop with a bazillion lines of code to print the time.

Get rid of the useless curly braces and the useless comments. Everybody knows that delay() causes a delay. It really isn't necessary to add a comment that says that delay() delays.

jurs

#19
Jun 10, 2015, 06:32 pm
This all of course is predicated that I can find why Relay_B is only pulsing when it should be constant HIGH like that of Relay_A.
You don't try to drive a relay directly from the 20mA that an Arduino output pin can deliver, don't you?

When you write 'relay' you mean something like 'relay driving transistor' or 'circuit on a relay board' or something like that?

Except of very small "reed relays" with a "extra sensitive rating" you will need much more current than 20mA to switch a relay.

myggle

#20
Jun 10, 2015, 07:19 pmLast Edit: Jun 10, 2015, 07:21 pm by myggle
I have a Sainsmart 8 channel Relay Module that is rated to be driven from Arduino's source capabilities.  I do intend to ultimately put it on external power supply, but b/c of a shortcoming with EtherMega, I need to keep it with USB power for the time being.  I do wish to point out that I am able to set all 8 channels to HIGH, as in the blink sketch, and all 8 relays change states as desired, but for some reason, channel 2 only clicks to produce the pulse when used in the Phase_1 sketch.  Here is a pic of my AC wiring to help convey what I built thus far.

After this pic was taken, I put the connecting wires from N.O. to each receptacle.  Everything is 14 AWG.

The Serial Monitor is an application that runs on the PC. It displays serial data that the Arduino output.

Since the simple sketch works, add to it.

Put all the code for printing the time to the serial port in a function. Call that function from loop(). Do NOT clutter up loop with a bazillion lines of code to print the time.

Get rid of the useless curly braces and the useless comments. Everybody knows that delay() causes a delay. It really isn't necessary to add a comment that says that delay() delays.
Sorry, I'm still too new to code and languages, I don't yet know what constitutes as a useless curly brace.  Useless comments I will nix.  Will putting all of time blocks into a function make the sketch smaller or run smoother?

PaulS

#21
Jun 10, 2015, 07:59 pm
Quote
Will putting all of time blocks into a function make the sketch smaller or run smoother?
No. But, if you say that printing the time works fine, then we don't need to look, at the code to see what the "not working fine" code is doing.

As for the "useless curly braces" comment, sorry about that. It was code in another thread that had them.

jurs

#22
Jun 10, 2015, 08:18 pmLast Edit: Jun 10, 2015, 08:19 pm by jurs
for some reason, channel 2 only clicks to produce the pulse when used in the Phase_1 sketch.
Which is the sketch that causes the faulty relay switching?

nickgammon

#23
Jun 10, 2015, 10:47 pm
Quote
I pasted the snippet about the test and mistyped the includes by mistake with hopes I would not have to explain why they were defined in the first place.  Yet here I am again explaining them for other reasons.
The point is, that when you post code that clearly doesn't compile, we wonder whether you retyped the whole thing. In other words, are we looking at the code you actually tested? Maybe you reversed a > and a < somewhere? I don't want to seem pedantic, but copying and pasting the whole sketch is the way to go.

http://snippets-r-us.com/

You seem to have ignored my comments about why it was doing what it was, but just to check I've looked at your newer code. Look at this:

Code: [Select]
` if (relayBstate == true)  {     digitalWrite(Relay_B, TURN_ON);    Serial.print("\t");    Serial.println(F("Feeding the plants"));  //  Text printed to serial monitor    Serial.print("\t");  }  else relayBstate = false;  // Turn off time for FeedPump1, OFF 9:10am  {      digitalWrite(Relay_B, TURN_OFF);  } `

First, you normally don't test a boolean for "== true" because this looks cleaner:

Code: [Select]
`  if (relayBstate)`

Now, you think "what does 'true' or 'false' mean for a relay"? It is like saying "is my door true or false?".

Surely a better test would be:

Code: [Select]
` if (relayBClosed) ...`

Now we know that "true" means "closed" and "false" means "not closed".

Moving on ...

Code: [Select]
` if (relayBstate == true)  {   ...  }  else relayBstate = false;  // Turn off time for FeedPump1, OFF 9:10am`

If the relayBstate is false, make it false. How does this do anything useful?

Next:

Code: [Select]
`   if (relayBstate == true)    {     ...    }  else      relayBstate = false;  // Turn off time for FeedPump1, OFF 9:10am// this is always done ! ---------------------------    {        digitalWrite(Relay_B, TURN_OFF);    }`

If you indented your code with the auto-indent tool you might have spotted this. Regardless of relayBstate you always turn the relay off. Presumably not what you intend. Those lines do not fall under the scope of the else.
Please post technical questions on the forum, not by personal message. Thanks!

nickgammon

#24
Jun 10, 2015, 10:50 pm
I was hoping someone would point out the flaws in my test(s) so I can learn from my mistake(s), but I guess not.
I did point out the flaws, with my analogy about slapping yourself. Presumably you thought that was a joke and decided to ignore it. I try to re-cast programming problems as real-life problems to force people to think beyond "why does C do this" to "what is my logic doing"?
Please post technical questions on the forum, not by personal message. Thanks!

myggle

#25
Jun 11, 2015, 03:18 am
If you indented your code with the auto-indent tool you might have spotted this. Regardless of relayBstate you always turn the relay off. Presumably not what you intend. Those lines do not fall under the scope of the else.
It took me some time to digest what you said and it dawned on me that "else relayBstate = false;" needed to be cut, so I did, uploaded, same result.  I commented out digitalWrite(Relay_B, TURN_OFF);, uploaded and relay_B went high and stayed (yay!).  I then uncommented that digitalWrite and uploaded again and all of a sudden, relay_B behaved as intended.  I tested it for a 10 minute lapse of time and it went LOW at the intended time.  One observation is that one of the climate sensor conditions was also true (Relay_E) and the respective relay was high for the duration of the feed time test, so perhaps there is a bug in the relay module.  I will change the code for the climate tests to stay LOW and have the feed test become true to see if the relay pulses again.

In short, I do not know why, but my issue seems to have resolved itself for the time being.  I will keep reading to try and build a programmers thought pattern.

Robin2

#26
Jun 11, 2015, 11:08 am
I will keep reading to try and build a programmers thought pattern.
Maybe have a look at planning and implementing a program ?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up