LCD display blanking on me.

I am using the 4x20 i2c display in my arduino uno brewery project. I am using 6 digital outs as relay channels to the sainsmart 8-relay board, 2 digital outs to run some heavy SSRs, have a piggy-backed RTD temperature sensor shield, and the lcd display module. Initially, I was trying to run everything over usb power and appeared to be getting too much voltage drop, so I added a 7.4V 1.8A power supply with a 7805 regulator. That brightened up my display and seemed to eliminate the voltage drops. I now have 5.06V dropping to around 5.04V with many of the relays on. As an additional debugging step, I added 4.7uf caps to both sides of the 7805. I'm still having issues where the lcd display is going blank (and won't do anything with additional prints). I display 4 lines of data around once per second. By adding a bunch of extra delay()s in different places, it appears the lcd is going blank when I'm printing data to it. (Not while relays are switching, for example. BTW, they seem to be run by transistors and have diodes on them anyway). I have done everything I can to check the data, and have found nothing. I am padding my strings with spaces to 20 characters, ensuring that I have null termination, am verifying the return value of print is 20 and am checking each character passes isAscii(). If I do a begin() to reset the unit before each screen refresh, it will function without fail, but of course, that looks like crap. Has anyone had an issue similar to this?

thanks,
brian

Nobody, eh? That sucks. I guess I will have to use one of my keypad keys for a display reset function...

Would you show us your sketch?
A schematic is also very helpful to visualize the hardware wiring (especially for us old guys).

I can't really share my sketch. It's over 1000 lines of code. I feel like it's not a hardware issue (other than maybe with the lcd display unit itself.), as I'm using the I2C version, which should be impossible to screw up. I don't really have the tools to draw up a schematic that wouldn't take me a week either. I already spend 10-20 hours trying to figure out this problem, most of my attempts being dead ends. I suspect it's a bug in the LiquidCrystal code. I'm going to write one more demo sketch that prints all characters that isAscii() passes, and see if I can reproduce the issue that way. If that doesn't provide anything, I think I'm going to just use my workaround and move on.

thanks,
brian

I finally found some implementation code of isascii, and that may not be enough of a test. It's possible I have a bug in my string formatting code and am producing a character that looks fine printed on the serial output, but jacks up the lcd. I soooooo wish I could write in Java. Jarduino anyone?

cheers,
brian

Let me get this straight. You can see your equipment configuration, you know how the various parts are interconnected, and you know what code is being used. You got nowhere after 10-20 hours of troubleshooting so you asked for help.

After four hours you complained that no one had helped and then when someone responded with a request for more information you refused to provide that information.

Is that about right?

Don

Wow, there sure are no shortage of snarky tools around here. Yeah, let me post 1000 lines of code and spend 10 hours drawing schematics just so you can not answer my question in the first place. I was merely looking for suggestions or people that have had similar experiences... Thanks for the ever so helpful response. Do you troll every topic?

brian

Quibbling aside, I had a similar problem with a 2X10 lcd display. It was stacked on top of the arduino, so had more pins than needed connected. Ended up that if I made pin 10 (undocumented) LOW, it turned off the backlight. I could look at it with a flashlight and still see that characters were being printed, but could see nothing without the flashlight.
May help, may not.

Jack

Thanks, Jack, but in this case, the backlight is staying on, but the display no longer responds to print()...

thanks,
brian

I may ask some stupid questions, but are you positioning the cursor each time, or just using print() ?
Have you taken all the boards apart, and just run the arduino with the display?
Sounds like the display is not stacked on top of the arduion, can it be?
Maybe just show us your 10 lines of code where you send info to the display.

Good Luck.

Thanks for the ever so helpful response. Do you troll every topic?

You can find out by going to my profile and then using the link near the bottom: 'Show the last posts of this person'.

Don

floresta, looks like you know a lot about LCD displays. I am just a newbie, so can you help us out, so we can learn from your expertise ? Thanks, Jack

... so can you help us out, so we can learn from your expertise ...

Not without more information. We don't know what display he is using, we don't know what I2C adapter he is using, we don't know what code and what library he is using, we don't know how the display is connected to the Arduino, we don't know the physical relationship between his LCD and the relays, etc., etc.

Don

You'r right Don. We need more information (questions), to have a better idea what his setup is. (see, I am learning from you already).
Thanks, Jack

I'm using the display as in 'version 1 (only 4x20)' mentioned here: http://arduino-info.wikispaces.com/LCD-Blue-I2C As they recommend, I'm using the LiquidCrystal_I2C library mentioned here: https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads. It is not stacked on the arduino, as it has a 4-pin side connector. I am fairly certain the problem is not my hardware, because as I mentioned, the problem is happening while I am printing to the display, when everything else is in a steady state. The only other thing on the I2C bus is the RTD shield, and that is still functioning when this problem happens. The code is below. As I mentioned in my first post, the SSRs and 6 relays are controlled by digital out pins (2-9), and I cannot detect any voltage drops below 5.04V during operation.

thanks,
brian

char lcdData[4][21];

void displayLcdData() {
//lcd.begin(20,4);

for (int i = 0; i < 4; i++ ) {
lcd.setCursor(0, i);
padRight(&lcdData [ 0 ] );
_ byte len = strlen(lcdData*);_
_
if (len != 20) {_
_ Serial.print(F("Strlen wasn't 20: "));
Serial.println(lcdData
);
}
for (byte j = 0; j < len; j++) {
if (!isAscii(lcdData[j])) {
Serial.print(F("Found non-ascii byte for lcd: "));
Serial.println(lcdData[j]);
}
}
byte written = lcd.print(lcdData);
if (written != strlen(lcdData)) {
Serial.print(F("Bytes written didn't match! written = "));
Serial.print(written);
Serial.print(F(", strlen(buffer) = "));
Serial.println(strlen(lcdData));
}
}
}
void padRight(char *str) {
int length = strlen(str);
if (length > 20) {
Serial.print(F("WARNING: strlen of string is > 20: "));
Serial.println(str);
}
for (int i = 20; i > length; i--) {
str[i - 1] = ' ';
}
str[20] = '\0';
}
[/quote]*_

Are you able to load and run one of the example sketchs on page http://arduino-info.wikispaces.com/LCD-Blue-I2C

Which are you using :
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
LiquidCrystal_I2C lcd(0x20, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE);
LiquidCrystal_I2C lcd(0x20, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

lcd.begin(20,4); ?

Your board marked as noted:
NOTE: for displays with backpack interface labelled "YwRobot Arduino LCM1602 IIC V1"

Good luck, Jack

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

Yes, I do have the begin() in my setup(), I just have that commented one there for when I was resetting at each screen refresh. Please note: the display generally works. It will work for several minutes, displaying everything just fine, until a certain point, when it just stops displaying anything. The reason for that is what I'm trying to get to the bottom of. BTW, one of the developers of the RTD shield has a different display not running I2C, and seems to have the same issue. The difference is that his won't reset with a begin().

brian

Ha Bryan,
You say it works for several minutes, before stopping. I must have missed that earlier. is after any reset, or just when the boards have had a rest (cooled down)?
Is the UNO still working, or is it maybe stopped (you got a blinking light?).
Often a heat problem will allow electronics to work for a few minutes, until the heat builds up to a breaking point.
Sometime a program will eat memory for a few minutes, until it runs out of memory.
I don't know, does arduino allow recursive calls ?
I doubt you have a second lcd board to test with (sure would be nice).

Good luck, Jack

It seems to lock up the display around the same part of my program. At first, I was running a simulated brewing cycle which goes through a few different cycles before it gets to the sparging process. I noticed that it kept happening during the sparge, so I put a shortcut to the sparge cycle in my menu, and it still happened during sparging. I will have to check if I have any parts that seem to bet getting hot. I also have a function to check for available memory, so I will put that into the display function as well. I think I will also try printing hex codes of every character to the serial port to ensure I'm not handing it some bad data that it doesn't like. Thanks for the tips. It's just so frustrating when you've spent like 2 grand on equipment and you get such a tiny little nitpicky problem that you can't solve. If you're interested in seeing what I'm working on, check this out: https://www.facebook.com/brian.krahmer/media_set?set=a.563154907059365.1073741826.100000945833806&type=3

thanks,
brian

You say it seems to be happening during the sparge cycle.
What if you bypass that in the code. Will it also bypass the problem?

I know a bit about frustrating projects. Keep plugging away.
Good luck, Jack