Garbled LCD screens

[Roxy]

To clarify for the interested, the interface involved with at least these display panels consists of six dedicated pins on the Arduino processor. i2c isn't involved. SPI is ran to the panel on at least the RepRapDiscount smart controller, but it is used with the SD card, not the LCD module. The six pins consist of an enable, a register select, and four parallel data lines. Low level operations involved with setting the data lines and toggling the enable and register select pins are accomplished through Arduino LiquidCrystal library functions. Marlin code takes care of higher level stuff like menu structure.

It could be there's more than one thing going on, but static discharge is definitely a way I've seen my display mess up.

I don't remember why I was thinking i^2c was used. I think I was looking at some of the smaller Arduino boards that had less I/O pins and that ended up being how a given LCD Panel worked with it. Your explanation about each character being transferred as 2 nibbles is helpful. I think what you are saying is there is no signalling to the LCD Panel to tell it which 1/2 of the character it is receiving. It just starts in the right state and every other nibble that is transferred to it is the start of another character. That seems like it is just asking to get out of phase if anything unexpected happens.

It would seem they should have some way to reset the panel and get it to a known state???

Another question is this: Since a lot of the LCD Panels use the same support chip, does this happen equally often with all of them? Or does it mostly happen with specific Arduino boards? Is there some combination that is more prone to the display getting out of sync? Is it at all related to how clean the power is? I know my PrintrBoard had trouble powering the Servo for Auto Bed Leveling. Do the LCD Display boards grab a lot of power from the Arduino board?

The reason for the questions is if the root cause of the LCD Panel getting out of sync is because of missing or double clocking of the nibbles... It would seem slowing that down and making sure there are nice clean edges to the Enable and Select lines after the data is stable would help. Right? But if the corruption happens because of noisy power or something else, the solution will be doing things to clean that up.

UPDATE: And the more I look at this, the more I don't know. Pulling up this link: http://www.reprap.org/wiki/RAMPS_LCD it shows how to build the LCD Panel and it claims it is enabled by taking the comments off of the #define ULTRA_LCD line. But when you look at their directions, they are saying the LCD Panel has 8 data lines and they only hook up 4 of them???? It would seem they should have some 'illegal' combination of RS, R/W and Enable that causes the display chip to reset????

Oh and here is at least one example of an LCD Panel using i^2c: Check out: http://blog.reprap.org/2008/10/new-b...oller-v10.html That must be why I was thinking they were using i^2c in general for this stuff.

[printbus]

...Pulling up this link: http://www.reprap.org/wiki/RAMPS_LCD it shows how to build the LCD Panel and it claims it is enabled by taking the comments off of the #define ULTRA_LCD line. But when you look at their directions, they are saying the LCD Panel has 8 data lines and they only hook up 4 of them???? ...

The display modules DO have 8 data lines, but the controller chip supports a data transfer mode that only uses four of them. The modules also have a read/write signal, but common applications don't need to read anything back from the display so they're hardwired for write-only. Using the 4-bit mode saves Arduino pins. (I'll get to i2c savings later)

It would seem they should have some way to reset the panel and get it to a known state??? ...It would seem they should have some 'illegal' combination of RS, R/W and Enable that causes the display chip to reset????

One would think, but no. "Initialization" involves sending a particular sequence of commands to the display module, with specific timing constraints on the transfers. That's all my "fix" is doing - periodically reinitializing the display by going through that command sequence again. There's a bit of delay in doing this, but I don't notice it on my printer. If I understand Marlin right, any printing going on should be handled in interrupts, so the additional time spent reinitializing the display shouldn't affect anything.

Since a lot of the LCD Panels use the same support chip, does this happen equally often with all of them? Or does it mostly happen with specific Arduino boards? Is there some combination that is more prone to the display getting out of sync? Is it at all related to how clean the power is? I know my PrintrBoard had trouble power the Servo for Auto Bed Leveling. Do the LCD Display boards grab a lot of power from the Arduino board?

I think there's too many variables here. I've had static issues on non-printer and non-Arduino designs using the modules, minimized by simply putting the display behind a bezel. They don't all use the same Hitachi HD44780 controller chip. There are clone chips out there. Older boards have discrete chips. Newer boards have the substrate right on the board and coated over. They just all support the same command set as the original HD44780 chips. Then, there's different module circuit board layouts that could lead to differences - maybe trace routing differs, different ground distribution, or maybe some include decoupling capacitors, who knows. Also, maybe some of the Arduino clone boards are better quality than others. Cleanliness of the power supply could make a difference. Wire routing in the printers could make a difference.

The core of the LCD modules I've used only need a couple of milliamps of power. If used, a backlight will draw more, but displays with the typical LED backlighting will still be relatively low. I would assume that those reprap displays with the rotary encoder and SD card still draw minimal power.

---------------

Rather than ramble on here, I'll touch on i2c in another post.

[Roxy]

One would think, but no. "Initialization" involves sending a particular sequence of commands to the display module, with specific timing constraints on the transfers. That's all my "fix" is doing - periodically reinitializing the display by going through that command sequence again. There's a bit of delay in doing this, but I don't notice it on my printer. If I understand Marlin right, any printing going on should be handled in interrupts, so the additional time spent reinitializing the display shouldn't affect anything.

OK... But here is the next question... If you are sending some 'Initialization' sequence, does that involve sending it bytes of data to give it commands? Because if it does and the LCD Panel is out of sync, aren't the 'Initialization Commands' scrambled?

[printbus]

OK... But here is the next question... If you are sending some 'Initialization' sequence, does that involve sending it bytes of data to give it commands? Because if it does and the LCD Panel is out of sync, aren't the 'Initialization Commands' scrambled?

Aw, man. I guess I should have known better than to gloss over details. State of the RS (register select) pin when the E pin is strobed is how the LCD module differentiates commands from data. At the start of the initialization sequence the LCD module doesn't know if the transfers will be 4-bit or 8-bit, but the first commands used only have four valid bits, and the others are don't care. So, the multiple-nibble synchronization problem can't occur on those first commands.

EDIT: I'd summarize the interface these modules have as fairly clunky by today's standards. I don't know how long the interface has been out there - I bought my first module off the surplus market in 2004, so I'm guessing it's been out there 15 years or so.

[printbus]

Evolution of Marlin took a different approach to the garbled LCD screens that negates the need for the fix proposed here. I don't know when it was changed in Marlin, but the Sept 28 2014 MakerFarm dacb fork now calls the lcd_implementation_init() whenever the printer is displaying the status screen and the LCD panel button is pressed. So, the display recovery occurs as soon as you press the button - you don't have to wait for the display to timeout before the LCD interface is reinitialized like my fix did. The additional delay spent reinitializing the interface before the top menu comes up isn't significant.

So, if you get the garbled LCD display on your printer with a fairly current version of Marlin, you can either just press the knob on the panel or you can insert/eject the SD card.