next topic »

[on:]

I apologize if this has been covered elsewhere, but I've done a bunch of searches on "lcd corrupt" on the forums and never really found anything that 100% pertains to what I'm experiencing.

To give you a brief overview, I'm making a temperature controller for my lager beer I'll be storing over the next few weeks.  For my setup I have an Arduino Uno running as the controller, with a DS18B20 temperature probe (sourced from Adafruit) and a standard HD44780 16x2 LCD display which displays the current temperature, the desired target temperature, and the controller status.  Running the actual refrigerator is a PowerSwitch Tail II (also sourced from Adafruit) which I bought because of the opto-isolated relay circuit so I can simplify my wiring.

I'm a beginner to Arduino so I cracked out the following (messy) code to run my compressor:

Code:

//Beer cooling controller

#include <OneWire.h>
#include <DallasTemperature.h>
#include <LiquidCrystal.h>

// Data wire is plugged into port 8 on the Arduino
#define ONE_WIRE_BUS 8
//Compressor Control is wire 9
const int Compressor = 9;
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Load the drivers and output pins for LCD Display
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
DeviceAddress beermometer;

//Variable setup for target, actual and timing
double currenttemp = 0;
const int targettemp = 35;  //target temperature for lagering
unsigned long motordelayTIME = 0;
unsigned const long motordelayconst = 330000ul;  //delays fridge motor for at least 5 1/2 minutes to prevent unnecessary cycling
boolean CompressorStatus = false;
boolean CompressorSafe = true;

void setup(void)
{
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Start up the onewire library
  sensors.begin();
  sensors.getAddress(beermometer, 0);
  // set up output on compressor
  pinMode(Compressor, OUTPUT);
}

void loop(void)
{
  // call sensors.requestTemperatures() to issue a global temperature
  // request to all devices on the bus
  if(millis() - motordelayTIME > motordelayconst) {
    CompressorSafe = true;
  }
  else
  {
    CompressorSafe = false;
  }
 
 
  sensors.requestTemperatures(); // Send the command to get temperatures
  currenttemp = sensors.getTempF(beermometer); //get the temperature in fahrenheit
  if((currenttemp >= targettemp + 1) && (CompressorSafe == true))
  {
      digitalWrite(Compressor, HIGH);
      CompressorStatus = true;
    }
   
  if(currenttemp <= targettemp - 1) {
      if(CompressorStatus == true) {
        motordelayTIME = millis();
      }
      digitalWrite(Compressor, LOW);
      CompressorStatus = false;
  }
  //LCD printing section to display running data
  lcd.setCursor(0, 0);
  lcd.print("Curr. Temp:");
  lcd.setCursor(11, 0);
  lcd.print(currenttemp);
  if(currenttemp <= 10) {
    lcd.setCursor(12, 0);
  }
  else {
    lcd.setCursor(13, 0);
  }
  lcd.setCursor(0, 1);
  lcd.print("TGT:");
  lcd.setCursor(5, 1);
  lcd.print(targettemp, DEC);
  lcd.setCursor(13, 1);
  if(CompressorStatus == 1) {
    lcd.print(" ON");
  }
  else {
    lcd.setCursor(13, 1);
    lcd.print("OFF");
  }
  delay(5000);
}

On the test bench it works flawlessly and has done a great job.  However, after what I've guessed is about an hour of continuous running, the LCD display goes from this:



To this:



I've tested the system by warming the probe with my hands and dumping into ice water as it's set to 35 degrees Fahrenheit.  The system responds normally by turning the compressor on and off, so I'm guessing the problem is isolated to the LCD screen.  Does anyone have any experience with this sort of thing, and have any advice as to what's happening with the LCD?  I'm honestly confused at this point - I've added delays and pared down the code to save on memory, but regardless of what I try I'm still not getting it to work right.  I'm pretty new to the Arduino and coding in general, so if any of you have any insight (or just good tips regardless of the LCD issue or not) I'd greatly appreciate it.  Thanks in advance!

Also, in case you are curious (or if this would make a serious difference) attached is a wiring diagram of my setup:

[Reply #1 on:]

I suspect the code but from reading through it I have not found mistakes yet. Since your LCD still accepts commands (set cursor still works), the display is probably good. Something wrong with arduino program. Can you pull the PowerSwitch circuitry out of your setup and test again? Maybe there's interference. I'm a bit suspicious on how you connected the PowerSwitch to arduino. Is that connection from adafruit?

[Reply #2 on:]

When running in 4-bit mode, you should really ground DB0 to DB3 on the LCD.  This will prevent floating inputs from causing any interference in the display (it might be switching back to 8-bit comms mode for example).

[Reply #3 on:]

On the test bench it works flawlessly and has done a great job.  However, after what I've guessed is about an hour of continuous running, the LCD display goes from ....

This phrase is a little ambiguous.  Is the following interpretation of what you are saying correct?  On the test bench, without connecting the refrigerator, it works flawlessly and has done a great job no matter how Long I run it.  When it is actually controlling the refrigerator, after about an hour of continuous running, the LCD display goes from ....

Now - about the messed up display.  It appears that the variables, the current temperature, the target temperature, and the status are being displayed correctly and it is only the titles that are messed up.  Is that always the case?  Is the messed up information always the same or does it change?  If it changes then once it starts getting flaky does it ever display the correct information again?

You could try displaying the titles in setup() since they never change.  This might fix up the display although we will not have determined the cause of your current problem.

By the way, if your current temperature drops below 10 degrees you are going to get an improper display since you aren't blanking the character in position (12,0). 

Don

[Reply #4 on:]

I'm a bit suspicious on how you connected the PowerSwitch to arduino. Is that connection from adafruit?

This connection is not correct.   I don't think it is the cause of your problem but you should fix it.  If you are going to use 'high side switching' you should be using a PNP transistor.  The more common technique is to use an NPN but put the Power Switch Tail in the circuit between +5v and the transistor collector (VDC+ to +5v and VDC- to the collector).  Connect the emitter to GND.

Don

Edit: "I don't think it is the cause of your problem .... "  I take that part back.

[Reply #5 on:]

When running in 4-bit mode, you should really ground DB0 to DB3 on the LCD. 

True, but nobody really ever does this....

This will prevent floating inputs from causing any interference in the display

Those inputs are ignored by the LCD controller in 4-bit mode but they could cause excessive activity (and therefore power consumption) by the controller.

(it might be switching back to 8-bit comms mode for example).

That won't happen.  It will only switch back to 8-bit mode after receiving 0011 on the four high bits, three times in a row.

Don

[Reply #6 on:]

That won't happen.  It will only switch back to 8-bit mode after receiving 0011 on the four high bits, three times in a row.

Surely that should say "shouldn't", not "won't".  We're working with an inductive load, and breadbord.  Both coupled together throw most "won'ts" out of the window.

[Reply #7 on:]

I meant that it wouldn't happen based on inputs to the lower data pins.

Don

[Reply #8 on:]

That looks to me like a classic symptom of memory corruption. I cant find the problem in your code, so perhaps there is a problem in one of the libraries. Which versions of the OneWire and DallasTemperature libraries are you using, and where did you download them from? Also, are you using Arduino 1.0 or an earlier version?

[Reply #9 on:]

This phrase is a little ambiguous.  Is the following interpretation of what you are saying correct?  On the test bench, without connecting the refrigerator, it works flawlessly and has done a great job no matter how Long I run it.  When it is actually controlling the refrigerator, after about an hour of continuous running, the LCD display goes from ....

Now - about the messed up display.  It appears that the variables, the current temperature, the target temperature, and the status are being displayed correctly and it is only the titles that are messed up.  Is that always the case?  Is the messed up information always the same or does it change?  If it changes then once it starts getting flaky does it ever display the correct information again?
 

Don

Sorry, should have clarified that better.  Yes, you are correct that I was running it for a short period without the connection to the refrigerator, something like a 15 minute test just pulling the probe in and out of cold water.

As for the messed up display, no, the variables are not always present.  This was just a fluke - normally they'll be replaced with random symbols and letters as well.  I'm not entirely sure why the targets and temperatures were staying that way, but I do know that with the example shown the actual temperature of the test probe was about 35 degrees and not 40.  The messed up information is always different as far as I can tell, I cannot see any patterns or recurring themes.  In the tests I've run so far, I have not seen it return to a normal state from the corrupted state.

This connection is not correct.   I don't think it is the cause of your problem but you should fix it.  If you are going to use 'high side switching' you should be using a PNP transistor.  The more common technique is to use an NPN but put the Power Switch Tail in the circuit between +5v and the transistor collector (VDC+ to +5v and VDC- to the collector).  Connect the emitter to GND.

Don

Edit: "I don't think it is the cause of your problem .... "  I take that part back.

Thank you very much for pointing this out!  I've corrected the connection per your advice.

I suspect the code but from reading through it I have not found mistakes yet. Since your LCD still accepts commands (set cursor still works), the display is probably good. Something wrong with arduino program. Can you pull the PowerSwitch circuitry out of your setup and test again? Maybe there's interference. I'm a bit suspicious on how you connected the PowerSwitch to arduino. Is that connection from adafruit?

After running a test to confirm the NPN connection is correct I will disconnect the PowerSwitch and let the device run overnight to see if the same error is generated, so I'll get back to everyone when I can confirm that.

As for why I'm using a transistor to operate the PowerSwitch:  I originally tried connecting the PowerSwitch directly to the Arduino pin and ground, however when the switch connected it blanked out the LCD display.  I assumed this was because the combination of the LCD backlight, LCD text, the power needs of the temperature probe and now the PowerSwitch drew too many milliamps for the Arduino power supply to hold.  That's when I did my (backwards) wiring of the transistor to help pull the current directly from the power supply to run the PowerSwitch, which worked well overall.  

That looks to me like a classic symptom of memory corruption. I cant find the problem in your code, so perhaps there is a problem in one of the libraries. Which versions of the OneWire and DallasTemperature libraries are you using, and where did you download them from? Also, are you using Arduino 1.0 or an earlier version?

The Adafruit site pointed out the links to the appropriate libraries where I downloaded the information from.  For the Dallas Temperature Control Library, I used the following site http://www.milesburton.com/?title=Dallas_Temperature_Control_Library and downloaded 3.7.2 which I'm assuming is the current version.  As for OneWire, I pulled it from here http://www.pjrc.com/teensy/td_libs_OneWire.html.  I have updated to Arduino 1.0 as well.

I'm grounding out DB0 to DB3 per the advice earlier.  It's not a problem at all on a breadboard, so better safe than sorry.  Thanks again for everyone's help!

Edit:
Also, thanks Don for pointing out the issue in the code with the temperature drop beneath 10 degrees.  I'm pretty certain I'd be scratching my head for weeks over that one.

[Reply #10 on:]

As for the messed up display, no, the variables are not always present.  This was just a fluke - normally they'll be replaced with random symbols and letters as well.

That makes a big difference. My original theory was that the RAM copies of the text strings were getting corrupted, hence they print incorrectly but the figures still print correctly.

Does it make any difference if you print all the strings direct from flash memory, like this:

Code:

 lcd.print(F("Curr. Temp:"));

and similarly for the other 3 strings?

[Reply #11 on:]

.... something like a 15 minute test just pulling the probe in and out of cold water.

Maybe a silly question but are you sure the probe is water proof?

--- bill

[Reply #12 on:]

After fixing the transistor wiring I let the Arduino run for about an hour and came up with the same issue.  Then I unplugged the PowerSwitch II from the breadboard and reset the entire system.  I let it run overnight and after returning home from work the screen was displaying correctly.  I'm assuming that something is happening with the PowerSwitch II, either that it's backfeeding into the Arduino (is this possible?) or that my wiring is really messed up. 

Adafruit claims that the PowerSwitch II is opto-isolated so there shouldn't be a need for transistors or relays to isolate the relay driving part of the circuit.  However, do you think I should use a 5v relay and try to further isolate the switch?  Or would that do next to nothing?

Does it make any difference if you print all the strings direct from flash memory, like this:

Code:

 lcd.print(F("Curr. Temp:"));

and similarly for the other 3 strings?

I'll go ahead and try that this evening and report back if it makes a difference.

Maybe a silly question but are you sure the probe is water proof?

--- bill

Not a silly question by any means.  I purchased it off of Adafruit (here's the link: http://www.adafruit.com/products/381) and their website claims it is "waterproof".  I'm not getting any bizarre readings from the system when immersing the probe immediately, and after disconnecting the PowerSwitch II the Arduino seems to be working well.  I'm not saying that the probe isn't a part of the reason, but it doesn't seem to be the sole source at this point.  Thanks for the suggestion though!

[Reply #13 on:]

Try running the system with a non-inductive load such as a some light bulbs instead of the refrigerator.   The problem seems to be interference messing up the LCD controller and the compressor is the most likely source.  

If this is the case you may be able to correct things by neatening up your wiring and/or by making the six leads between the Arduino and the LCD as short as possible and as far away from the refrigerator wiring as possible.

Don

[Reply #14 on:]

The messed up information is always different as far as I can tell, I cannot see any patterns or recurring themes.  In the tests I've run so far, I have not seen it return to a normal state from the corrupted state.

This sounds like a clue.
Does the temperature ever change after the corrupted state?
The sketch attempts to update the display about every 5 seconds
so if it isn't, It sounds like the AVR processor (or LCD controller) may be crashed.

It looks like the board is being powered from 12v. Where is that power coming from?
Maybe that supply is getting a giant power surge when the frig kicks on/off that
is crashing the AVR or LCD.

Maybe you could put in a small "heartbeat" in the loop to blink the LED on the Arduino
after each lcd update.
That or for even more information perhaps toss in a few serial prints to see where the code is "freezing".
Toss in a print maybe before and after calling the temperature library functions to
see if the temperature library is hanging, maybe print the temps themselves, etc....
Then leave it running with the serial monitor window up
just to give an idea if things are still running or where they hang.

--- bill