Just to clarify i am new to arduino and have only used it for about 5 months in my masters project, so i am in no way a master in coding or wiring.
I’m sorry if i missed any rules regarding posting.
I have something called a membrane bioreactor that i am trying to monitor using two arduino setups.
One freezes anywhere between 12 and 24 hours while the other crashes between 48 and 72 hours.
The one that freezes in 24 hours is powered by a 9V 1A powersupply, and consists of a SD card reader, a LCD, a RTC, a conductivity sensor, a load cell connected to an amplifier, two temperature sensors and a relay controlling a 24 V solenoid valve. I have attached a diagram drawn in fritzing.
The setup is supposed to monitor weight, conductivity, temperature and print this and a timer, the date and time to a SD card, while simultaneously printing it to the LCD so i also can monitor it real time.
However, it freezes at a seemingly random place in the code before 24 hours has passed.
The latest fix i tried was to remove the conductivity sensor to see if this resolved the problem, which is why the code pertaining to this is commented.
Can it be a memory problem or anything like that? Any answer is greatly appreciated.
The code is attached, i went over the limit if i pasted it here, i apologize.
When you are going to have useless comments, you MUST make the useless comments match the code. Them's the rules. No telling what will happen if you don't play by the rules.
Mixing millis() and delay() in the same code just does not seem like a good idea.
On the other hand, using Tools + Auto Format, to properly indent your code DOES.
Arnoz:
However, it freezes at a seemingly random place in the code before 24 hours has passed.
Possible causes for that are writing past the end of an array or simply running out of SRAM.
You are using a lot of libraries and unfortunately few (if any) library authors take the trouble to see if their pride-and-joy works harmoniously with other libraries.
How much RAM does the compiler report is available? Use of the F macro would get you some more.
Why aren't you using the more conventional library for the RTC?
I don't see anything wrong in your code. That said, I'd suspect heap issues or array overrun. I wonder if any of your libraries are allocating memory or using String.
I don't really see that opening the file on every iteration of loop is wrong, but it doesn't smell right. Consider flush instead.
Edit: Get yourself a copy of the freeMemory() function and see if you have a leak.
What does it mean to write past the end of an array?
if you have an array with 7 elements and your program writes to the 8th element - which is really memory belonging to something else.
And how do i run out of SRAM? What gets saved on it?
SRAM is the scratch-pad for all the calculations that the program does. It is where all the variables are stored. Some of the code in a library might be using memory wastefully and not cleaning after itself.
I don't think i can do that, because the SD card cannot write on the SD card when the monitor is open.
I have put a diode in parallel on the + and - on the valve.
Sadly i can't do without the valve, since it is a very vital part of what i am trying to examine
I had even more problems before putting in the diode and at that time it would always crash when the relay is turned on or off (I can see on the LCD where code is at), but now it freezes at a seemingly random part of the code, the last two times it was at the conductivity part, then it was at the second thermometer).
Robin2
Oh i see, thank you for explaining that, i will try to examine the libraries and hopefully find something if i understand them!
Disconnect relay for purpose of testing, and see if it still freezes (switch an LED instead or something). I predict it won’t - non-deterministic freezes or reset are almost always either writing off end of array, stack-heap collision (caused by dynamic memory allocation - String class is the main offender here - the typical usage patterns are also the worst case for memory problems), or switching of inductive loads (motors, relays, solonoids) causing a glitch on the power rails that leads to instability. With no clear evidence of the first two (software) causes, I suspect the third cause.
It is often necessary to use a second power supply for inductive loads, though better power supply filtering often helps. Large coils, as well as anything that generates an arc, will result in EMI that can be picked though the air (enclosing the electronics in a conductive case connected to ground, and/or any long wires located near the source of the EMI in shielded cable with shield grounded is the typical solution)
I will try to disconnect the relay and see if it helps.
However, i have a setup very similar to this one without a relay that also freezes just not as frequent, and this box is about a half meter away from the relay. Can the interference travel that far?
Arnoz:
Oh i see, thank you for explaining that, i will try to examine the libraries and hopefully find something if i understand them!
When looking at the code in libraries be on the lookout for the use of the String (capital S) class.
It is not a good idea to use the String (capital S) class on an Arduino as it can cause memory corruption in the small memory on an Arduino. This can happen after the program has been running perfectly for some time. It is much better to use cstrings - char arrays terminated with '\0' (NULL).
However, i have a setup very similar to this one without a relay that also freezes just not as frequent, and this box is about a half meter away from the relay. Can the interference travel that far?
The problem is more about grounding, common ground point, and type of wiring used.
What relay / relay board do you have? Today optically-isolated relay boards are low cost and can solve many traditional EMC problems. Here is a page that can help understand these issues. I think you may find it helpful in considering the physical and electrical reality of what you have put together.
When you're doing an operation on something that returns a pointer (to an object or anything else) it's a good idea to ensure that the pointer is valid before using it.
For example, SD.open() returns "...a File object referring to the opened file; if the file couldn't be opened, this object will evaluate to false in a boolean context"
You shouldn't assume that the file-open occurred properly. Check myFile to ensure it's valid before doing any writes:
It might not be your problem (though passing an invalid pointer to a data transfer method can't help but cause chaos...). Nevertheless, it's good practice to check your pointers.
The freewheeling diode is drawn backward (short circuit) and in wrong place, should be across valve coil, not across power supply, does no good where it's at (before relay contacts). Kickback current has nowhere to go with contacts open.
Can you run your Arduino while it is connected to the Arduino Serial Monitor (or equivalent program) and have it print some messages from different parts of the program. That should allow you to tell if it always crashes at the same point in the code - i.e. somewhere after the last printed message.
Because i have the LCD connected i can see what part of the code was run just before it crashes.
For example, when reading weight it will save it to the SD card, and then print it on the LCD, then it will read temperature, and then print it to the LCD.
The weird part however, is that it seems random what part of the code it crashes at. I've had it crash at a temperature measurement, a conductivity measurement, and when the relay is turned off.
I went down the my system today, and here at noon my second system was frozen after about 20 hours, and that system is similar but has less parts than the one I've explained in this topic. So i'm getting more and more confused.
I see that the SD library is doing dynamic memory allocation when a file is opened, so you have potential for trouble if any other part of your code is allocating. Do you have anything in there displaying free memory yet?
I'd be inclined to run the code with all your delays substantially reduced and see if you can crash it without having to wait a day to see results.
I'd also either open the output file once as mentioned earlier or close and reopen it hourly. Note that the latter may just hide the problem rather than solving it.
After that I'd also put a lot more serial.prints in there, but be aware that doing so may change behaviour.
Another way to hack around the issue would be use of the watchdog timer (q.v.). Some of those big delays would probably have to go though.
Arnoz:
Because i have the LCD connected i can see what part of the code was run just before it crashes.
For example, when reading weight it will save it to the SD card, and then print it on the LCD, then it will read temperature, and then print it to the LCD
Is the SD Card always involved shortly before the crash?
I can't see where you have told us what Arduino board you are using.
If you are using an Uno it would be interesting to see if the crash is postponed by using a Mega which has more SRAM. Note that a Mega will NOT solve the problem - but if it behaves differently it may help to isolate the cause of the problem.
Hi,
That relay's PHOTO shows it is optically isolated. The schematic diagram on that page is different; non-isolated. Can you confirm the relay you have IS same as photo?
UPDATE: The seller confirmed to me that it is the isolated version. (CAN be isolated). Seller changed the photos, now.
If so, it CAN be isolated if wired correctly. You will need a small 5V power supply to operate the relay independently from your Arduino.
See THIS page/section about how to wire it for isolation.
