I am new to this forum and if I am writing to the wrong place, please indicate.
The code I have written reads temperature from DSB1820 sensor and according to that applies some output commands. But that reading will be displayed when the related menu option is selected.
My problem is with lcd.print command. For the menu "Su Sicakligi" the temperature reading is fine at first, but after a while display becomes with weird characters. When I change the command lcd.print(su_sicaklik,2) with lcd.print("abc") then it works properly! However if I change with lcd.print("5.0") again it is not working properly. I have realized that the display cannot show digits, especially 0 continiously.
Do you have any idea? Is the library broken? Or is there a something missing point?
bperrybap:
Are you using a relay on pin 35?
If so, I would guess it relates to using the relay.
Can you show us your schematic and your wiring?
---- bill
Yes, there is a relay on pin35. However, the system can work greatly when I make comment the command line "su_sicaklik=getTemp();". I think the getTemp function breaks the LCD library or something else somehow. I could not understand.
I found the same problem from topic at the late midnight. He solved the problem with replacing the arduino and sensor with newer one with his same code, yet it does not seem logical. Here is the topic:
That's an impressive design but it is centered around a Mega and I do not have experience with the big nephew of my modest Nano's. My knowledge of second languages, i.e., other than English is not so good either I must admit, so it is difficult to follow the sketch. It has to do with pump control ? However I have the feeling that at some point the menu management goes berserk and produces a long string of output that overwrites all characters of the lcd display and produces the funny output seen on your picture. You can test every step of your sketch by echoing a copy of all lcd output to Serial Monitor. Is <Keypad.h> standard or an 'acquired' library?
Usually if something goes wrong I do the following
test independently each hardware component: does it work properly (seems it does in your setup)
test each software module independently
build up the final sketch module by module and debug all the time with Serial Monitor
That's an impressive design but it is centered around a Mega and I do not have experience with the big nephew of my modest Nano's. My knowledge of second languages, i.e., other than English is not so good either I must admit, so it is difficult to follow the sketch. It has to do with pump control ? However I have the feeling that at some point the menu management goes berserk and produces a long string of output that overwrites all characters of the lcd display and produces the funny output seen on your picture. You can test every step of your sketch by echoing a copy of all lcd output to Serial Monitor. Is <Keypad.h> standard or an 'acquired' library?
Usually if something goes wrong I do the following
test independently each hardware component: does it work properly (seems it does in your setup)
test each software module independently
build up the final sketch module by module and debug all the time with Serial Monitor
if all else fails, consult the manual
what is the RawValue= 0 for?
Hi PhotonCathcher,
Yes, you are right. The sketch is difficult to track, yet it is not the final version and the comments are in native language, sorry about that. You are right, it is a pump control unit!. It will control a kind of room heater.
Here is my answers to your concerns:
<Keypad.h> library is downloaded from internet and tested for only with 4x4 keypad and it is approved with serial monitor.
Since my project includes; buzzer, relay, lcd, keypad, temperature sensor(DS18B20) and current measurement sensor (ACS712) I have tested all components individually with sample codes and everything works properly.
Then I worked with two components; namely lcd&keypad, lcd&relay, lcd&buzzer, lcd¤t sensor and lcd&relay. Those worked greatly!
The problem again emerges when I try lcd&temp sensor. Indeed I can read the sensor output from serial monitor without any problem. Moreover, at the begining I can observe nice printing on lcd screen, yet after 1-2 cycle it crashes (at that time, I can still see read of temperature on serial monitor). Then I need to reboot the system.
I think somehow getTemp function breaks lcd communication, bu how?
By the way I could not find RawValue=0? Could you mention the command line #?
By the way I could not find RawValue=0? Could you mention the command line #?<<<
in the Hall sensor declaration section:
//ACS712 parameters
const int currentpin = A0;
float mVperAmp = 66;
int RawValue = 0;
float ACSoffset = 2.5;
float Voltage = 0;
float Amps = 0;
float current=0;
Given your comment I checked the sketch. By the way, there is a lot of commented-out instructions that distract me. From your comment I assess that there may be a lcd display addressing problem.
I advise to check cursor positioning control in all if-s and while-s and in all subroutines. You apply a minuscule 16x2 LCD display which has a limited number of characters to display. If not properly controlled, words will overrun a line and be displayed on a next line, screwing up the device. For instance, in void sistem_reset(), line 567 states: "lcd.print("Sistem Basliyor...");" This string is 18 characters - it overruns row 0 of your minuscule lcd display to spoil two periods into the next row.
For example: in void manuel_pompa() there is a lcd.setCursor 0.1 followed by lcd.print(" "); which is 12 empty characters. Next there is an if that points to whatever it produces at lcd.print(deger.toInt());
I would be inclined to insert in all proper lines a lcd.clear() instruction to empty the display character buffer before you issue the lcd.setCursor(0,1) followed by the parameter-to-be-displayed
You may also first convert the temperature value (i.e., a float) to a string using mystring = String(f) where f is the float variable, and then handle over to the lcd display.
Another thing that worries me is instructions like " name=deger.toFloat(); Floats may posssess a lot of decimals. Do you cut off the number of decimals, e.g. at 2 decimals, before printing the float to the display? Else use the float-to-string method.
Success !
For the hall sensor part, RawValue is redundance. Indeed when I copied the code from open source I have changed it to readValue and why I have introduce that variable in the function again. It is my mistake but it did not change anything.
After your advices I have tried lcd&TC with the following code:
#include <OneWire.h>
#include <LiquidCrystal.h>
OneWire ds(39);
LiquidCrystal lcd(53,51,49,47,45,43);
float temp;
float getTemp();
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);;
lcd.begin(16,2);
lcd.clear();
}
void loop() {
// put your main code here, to run repeatedly:
temp = getTemp();
delay(25);
lcd.setCursor(0,0);
lcd.print(temp,3);
}
float getTemp(){
byte i;
byte present = 0;
byte type_s;
byte data[12];
byte addr[8];
float celsius, fahrenheit;
if ( !ds.search(addr)) {
Serial.println("No more addresses.");
Serial.println();
ds.reset_search();
delay(250);
return;
}
Serial.print("ROM =");
for( i = 0; i < 8; i++) {
Serial.write(' ');
Serial.print(addr[i], HEX);
}
if (OneWire::crc8(addr, 7) != addr[7]) {
Serial.println("CRC is not valid!");
return;
}
Serial.println();
// the first ROM byte indicates which chip
switch (addr[0]) {
case 0x10:
Serial.println(" Chip = DS18S20"); // or old DS1820
type_s = 1;
break;
case 0x28:
Serial.println(" Chip = DS18B20");
type_s = 0;
break;
case 0x22:
Serial.println(" Chip = DS1822");
type_s = 0;
break;
default:
Serial.println("Device is not a DS18x20 family device.");
return;
}
ds.reset();
ds.select(addr);
ds.write(0x44); // start conversion, with parasite power off at the end
delay(1000); // maybe 750ms is enough, maybe not
// we might do a ds.depower() here, but the reset will take care of it.
present = ds.reset();
ds.select(addr);
ds.write(0xBE); // Read Scratchpad
Serial.print(" Data = ");
Serial.print(present, HEX);
Serial.print(" ");
for ( i = 0; i < 9; i++) { // we need 9 bytes
data[i] = ds.read();
Serial.print(data[i], HEX);
Serial.print(" ");
}
Serial.print(" CRC=");
Serial.print(OneWire::crc8(data, 8), HEX);
Serial.println();
// Convert the data to actual temperature
// because the result is a 16 bit signed integer, it should
// be stored to an "int16_t" type, which is always 16 bits
// even when compiled on a 32 bit processor.
int16_t raw = (data[1] << 8) | data[0];
if (type_s) {
raw = raw << 3; // 9 bit resolution default
if (data[7] == 0x10) {
// "count remain" gives full 12 bit resolution
raw = (raw & 0xFFF0) + 12 - data[6];
}
} else {
byte cfg = (data[4] & 0x60);
// at lower res, the low bits are undefined, so let's zero them
if (cfg == 0x00) raw = raw & ~7; // 9 bit resolution, 93.75 ms
else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms
else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
//// default is 12 bit resolution, 750 ms conversion time
}
celsius = (float)raw / 16.0;
fahrenheit = celsius * 1.8 + 32.0;
Serial.println(celsius);
return celsius;
}
The lcd does not working while the serial monitor shows the following:
Yes, it was still working for a period of time. However, after trying everything possible, I had played with the VCC and ground pins of LCD. When I removed the ground pin from the I/O PCB card which can be seen from the picture (on left-top, white cable) and leave it as floating, the system started to work amazingly. I could not understand, I have checked possible short-circuits, yet I couldnot found anything wrong. I also added the I/O card PCB layout.
To sum up I have solved the problem without any idea.
