Arduino Uno Timing issues

Hi everyone, this is a continuation of a previous thread https://forum.arduino.cc/index.php?topic=728998.msg4904126#msg4904126

Previously I thought the arduino was locking up, but I don't think that is the case now. After a period of time after being reset, it stops working correctly. I have tested every function that I've programmed and everything seems to work, but then days later when it's activated it doesn't work correctly. I was testing with it on Saturday night, and everything seemed fine, but then Monday afternoon when I manually triggered it, it wasn't functioning correctly. Here is what it should do:

  1. When the siren goes off, it arms and waits for motion
  2. When the motion is triggered, if armed, it will activate the sequence
  3. If the sequence is activated, it will open the doors
  4. 15 minutes after the doors are opened, it will close them
  5. While the system is armed, triggered, or a door is open, the lights will be overridden on
  6. While any door is open, the furnace will be off
  7. If the doors are closed manually 10 minutes after the system was triggered, it will reset and not attempted to close the doors
  8. Before the doors close, the lights flash a couple times by overriding them off

If I reset the system, I can sit and wait through all of the timeouts and see it work fine. System arms when it should, lights work, furnace works, every bit of that works perfectly. Once the system sits for a while it stops working correctly. When the siren goes off, the system arms, lights go on, and after that nothing else happens. The doors don't open, lights don't flash, and the lights never turn back off when the system is supposed to reset.

I think that I either have a faulty arduino, or there is some sort of timing issue related to millis() getting too big but all of my variables related to time are unsigned longs so I'm not sure why that would be an issue.

Ideas?

Station_Automation_Programming_V2.ino (21.2 KB)

lmfd1550:
I think that I either have a faulty arduino, or there is some sort of timing issue related to millis() getting too big but all of my variables related to time are unsigned longs so I'm not sure why that would be an issue.

You could get another Arduino or two to test your first hypothesis - always handy for this kind of troubleshooting.

How long does it take to go wrong?

You have rather a lot of status variables and your systemActivationLogic function looks complex. I'd suspect that there's something in there causing your problems. What are all those serial.prints telling you?

wildbill:
You could get another Arduino or two to test your first hypothesis - always handy for this kind of troubleshooting.

How long does it take to go wrong?

You have rather a lot of status variables and your systemActivationLogic function looks complex. I'd suspect that there's something in there causing your problems. What are all those serial.prints telling you?

Yeah, I do have another Arduino, but due to several compromises that had to be made in the project, it's difficult to replace it.
Hard to say how long. The data points I have say that it's more than a couple of hours, and less than 2 days assuming that it's consistent (which I have no idea if it's intermittent or constant).
The status variables show exactly what they should when attached and testing. The problem is that I don't have a laptop I can leave connected and monitoring for the days that it goes wrong. When I attach my laptop and open a serial connection it resets which puts it back into a well-running state. I've been looking into how to bypass the reset and I might be able to do it with a capacitor but I don't have one currently.

Another thing to consider is whether it comes back to a valid state after doing a cycle of opening doors etc. I.e. Does it work more than once?

If Arduino UNO, Nano, Mega, put a 100 ~ 470 nF capacitor from reset pin to GND, that will block the reset when serial connects. Have to remove it to program though.

JCA34F:
If Arduino UNO, Nano, Mega, put a 100 ~ 470 nF capacitor from reset pin to GND, that will block the reset when serial connects. Have to remove it to program though.

yeah, I just don't currently have one.

wildbill:
Another thing to consider is whether it comes back to a valid state after doing a cycle of opening doors etc. I.e. Does it work more than once?

Yeah, while testing each of the functions, I had to arm and trigger several times and it worked appropriately. (without resetting between)

I often suspect relays and motors when programs have issues. For testing can you replace all your relays with leds and see if the problem occurs?

Perhaps using LED's/resistors, GPIO pins and a bit of code, LED's could be made to energize and deenergize at particular spots of code execution. The state of the LED's at lock up could be used to zero in on the area of trouble.

Does a reset, not power down restore operations or is a power off/on thingy required to restore normal operations?

I would not use D1 for motionSen or D13 for furnaceRly. D1 is part of the Serial/USB interface, and D13 is the onboard LED control, which may cause your furnace relay to trigger if the Arduino resets. You can use A0 through A5 as digital input/output ports instead.

The problem may be unrelated to the arduino, such as spikes on the power line caused by something else in the building, radio frequence noise picked up on your wiring, etc.

You may want to implement a watchdog timer to reset the arduino in case it locks up, but this does tend to just mask the real problem.

Your system really needs to use opto isolation for ALL relays, but the worst issue is this ...

When the siren goes off, the system arms, lights go on, and after that nothing else happens.

Referring to the Pager Relay in your diagram, it shows that Arduino negative (GND) is tied to 120V Neutral. This is not good and will cause safety concerns - this connection needs to be removed! Isolation is urgently required here. Perhaps a spare set of contacts by using a DPDT relay could work, but ideally an opto isolator would provide best noise immunity. Could even use both DPDT relay and opto.

cattledog:
I often suspect relays and motors when programs have issues. For testing can you replace all your relays with leds and see if the problem occurs?

I don't think this is the case for a couple of reasons: All outputs are relays, no LEDs, and the things that stop working are the doors not being triggered (as well as some resetting logic) and it all works perfectly after a soft reset of the Arduino (so no reset of the relay).

Idahowalker:
Perhaps using LED's/resistors, GPIO pins and a bit of code, LED's could be made to energize and deenergize at particular spots of code execution. The state of the LED's at lock up could be used to zero in on the area of trouble.

Does a reset, not power down restore operations or is a power off/on thingy required to restore normal operations?

Thought about that, I am limited on my IO's due to my project being an Uno. As someone else pointed out, I can use the analog as digital I/Os so I might be able to give that a shot (might see if I can put a screen on it with those too.). My other thought is that it might be futile because there is no state where the doors are closed and the lights are on for an indefinite period of time, so I'm not sure yet what I can have my code tell me yet.

Yes, a reset, not power down (which I avoid because the motion sensor takes ~30 seconds to initialize) returns the unit to a working state.

david_2018:
I would not use D1 for motionSen or D13 for furnaceRly. D1 is part of the Serial/USB interface, and D13 is the onboard LED control, which may cause your furnace relay to trigger if the Arduino resets. You can use A0 through A5 as digital input/output ports instead.

Good tip, didn't seem to matter to use these. I will convert to the analog pins anyways. D13 does reset with the Arduino, (and I had wondered why), but it's fairly inconciquential to the setup as it happens so fast that there is no reaction from the furnace. To clarify, this interrupts the signal for "on" from the theromostat, so if the thermostat is not commanding a "heat" state, then the relay affects nothing, and even when it is, the relay reset is so short that the furnace ignores it and keeps heating.

david_2018:
The problem may be unrelated to the arduino, such as spikes on the power line caused by something else in the building, radio frequence noise picked up on your wiring, etc.

You may want to implement a watchdog timer to reset the arduino in case it locks up, but this does tend to just mask the real problem.

Yeah, I agree. I forgot to mention that before I knew that HIGH/LOW were stored as boolean, I had them set as int. during some of my debugging they would come back as having weird values like "378" rather than 0/1. After I converted them to boolean they can't store anything else, but I don't know where those weird values came from originally.
As for a watchdog, like you said, it would only mask a problem, and I think that it would adversely affect the performance of my project if it reset in the middle of an activation. There is no telling when we get a call, 3am, 3pm, so there is no good way to know if it's ok to reset.
I partially suspected the power draw from the siren (3 phase big mamma jamma) causing a brownout to the Arduino, but it happens even when I turn the power to the siren off and only it's controlling relay kicks. I could plug it into the UPS, but I specifically wanted it to reset when power was lost because we often have power outages and we respond to the cause of those outages and physically open the doors ourselves, or it gets opened and then the power goes out.

dlloyd:
Your system really needs to use opto isolation for ALL relays, but the worst issue is this ...
Referring to the Pager Relay in your diagram, it shows that Arduino negative (GND) is tied to 120V Neutral. This is not good and will cause safety concerns - this connection needs to be removed! Isolation is urgently required here. Perhaps a spare set of contacts by using a DPDT relay could work, but ideally an opto isolator would provide best noise immunity. Could even use both DPDT relay and opto.

The relay boards all have optocouplers built into them. so that it isn't as much of an issue. I do agree about the siren activation and I ordered an optocoupler about a month ago and it's taking the slow boat from china to get here. The issues I'm running into are finding one in the US, and finding one for 120V. While I agree that having a neutral in the project is not a good idea, functionally it's the same as a car ground. Neutral and Ground are tied together in the electrical panel, so for small currents, they react the same (obviously large currents there is a much different effect). So it's the same really as using the case of your project as a negative ground. I do agree that it is a problem, but I don't think it's what is causing the issues I am having (unless it's somehow a giant antenna absorbing EMI into the project). This is what I bought, but I still need to identify the correct resistor to swap in to make it work for 120v.

The problem with a relay for this is the current is so low, it's like 23 gauge wire that is a dry contact on the siren driver from the radio relay. Optocoupler is the best option, just finding a module for the project is my problem. I don't really want to build one as it wouldn't be pretty.

There are many things I could do otherwise to reconfigure how this is setup, but part of my goal is to not change what was previously in place and working for the past 20 years (I don't think any change I could make would improve the stability of the siren as it has a pretty much perfect track record). If I use the C and NO side of the relay, then it triggers the siren, so I have resorted to the C and NC side which is what forced the neutral to be tied it.... can't wait for that optocoupler.

The relay boards all have optocouplers built into them. so that it isn't as much of an issue

The only way to enable this feature is to use a separate DC supply for the relay board, remove the JD-VCC jumper and remove the GND connection from the relay board to Arduino.

I do agree that it is a problem, but I don't think it's what is causing the issues I am having (unless it's somehow a giant antenna absorbing EMI into the project).

But...

When the siren goes off, the system arms, lights go on, and after that nothing else happens.

Easy to test ... just disconnect the 2 wires from the Pager Relay to Arduino (GND and GPIO2) and see if the problem goes away.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.