Hallo 6v6gt
I disabled the pulllup resistor (digitalWrite(Bellpin, LOW); // disable internal pullup) in row 132.
Unfortunately without success.
My intention is to solve the problem by software (without diodes in the output line).
Otherwise I think to use a time delay relay with reed relay to prohibit the output pulse during the load process.
Enclosed my complete code
Slagwerk_20d.ino (30.3 KB)
On closer look, I see nothing to explain this.
Going back to post #10 where you have a very simple sketch which exhibits the same problem, did you observe the same behaviour with that nano out of the circuit ? In principle, apart from the pins previously mentioned, all pins are in a high impedance (floating) state during the upload process.
In your main sketch, you are using the String class which is always a discussion point when unexpected behaviour is exhibited but, of course, that does not apply to the post #10 sketch.
I'd start with a the post #10 sketch on a replacement Nano, out of circuit, and start from there.
Did you mean to make the condition of the if statement an assignment instead of a comparison?
//condition to strike the hammer
if (blnBellCycle = true) { // << this assigns the value 'true' to blnBellCycle
//Calculate the number of Pings
if (hour == 0) {
hour = 24; //Midnight is presented as 0:00, but the bell has to ring 12 times
}
if (hour >= 1 and hour <= 12) {
numberPings = hour ; //Fix number of beats for hours
} else {
numberPings = hour - 12;
}
if (minute == 30) {
numberPings = 1; //One beat for the half hours
}
Yes David_2018,
the clock runs from 00:xx upto 23:xx; the number of pings runs from 1 to 12.
But I want to focus to the short moment that the output goes high during uploading.
This
if (blnBellCycle = true) { // << this assigns the value 'true' to blnBellCycle
is not the same as
if (blnBellCycle == true) { // << tests the value blnBellCycle
the first (assignment) if statement condition is always true, the result of the assignment.
the second (== test of equality) controls whether the body of the if statement gets executed.
So “=“ looks odd in this circumstance, and will generate a warning since it is a common
mistake and uncommon if legal and arguably useful.
More readable code probably avoids assignment within the condition part of an if statement.
So when your focus returns to why something isn’t working the way you thought, you might look at that again first.
a7
Can you remove the Nano and see if the SSR remains off? This still seems like a hardware problem. Did the Nano come with pins/headers soldered on, or did you install them yourself?
Are you able to post some good resolution photos of the wiring and/or pc board? If pin 4 on the arduino is not damaged, then I would suspect leakage current somewhere in the SSR circuitry, some error in the grounding, etc.
The SSR works in the normal operation mode fine (all connected pins work good / yes self soldered)).
The problem is the status of the IO-pins during uploading.
Mostly the output has to zero (the church bell is not ringing).
After (a simulated) grid faillure the Arduino Nano will reboot and comes for a short while with a HIGH signal.
ArduinoStarter1:
. . .
After (a simulated) grid failure the Arduino Nano will reboot and comes for a short while with a HIGH signal.
This is not quite the same thing as instability during software upload which is what I understood originally.
This could be something in setup(), for example attaching an interrupt when an interrupt is already pending, a counter being reset to 0, or something similar. All this can be tested by simply pressing the reset button and see how it behaves.
Again, the simpler the test which demonstrates the problem, the simpler the problem analysis.
There are some other issues which I've just noticed in your main sketch:
cnt1 is set in an ISR so should be declared as volatile. The same with blnShowDateTime and blnOnTop.
Serial.print() also does not function reliably in an ISR.
ArduinoStarter1:
The SSR works in the normal operation mode fine (all connected pins work good / yes self soldered)).
The problem is the status of the IO-pins during uploading.
I'm not questioning the operation of the SSR during normal operation, at that point D4 is in output mode and actively driving the SSR. The problem appears to occur when D4 is in input mode, implying something is supplying current to the SSR at that time, and for a sufficient length of time to be noticeable.
Does the SSR turn on if you upload the example Blink sketch, code that should never do anything with D4?
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.