Garbled LCD screens

[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.

[Mjolinor]

I think much older than that. Being an old git my mind is unclear but I am sure I remember using a Z80 to talk to them possible as early as 1980.

[printbus]

I think much older than that. Being an old git my mind is unclear but I am sure I remember using a Z80 to talk to them possible as early as 1980.

You could be right. I just figured that if I got one surplus in 2004, they were likely out at least 5 years prior to that. Digging into my displays box, I now see one of them that I bought at the same time in 2004 has what is likely a date code of 1991 on it.

[printbus]

Looking good. Should someone want to add the display auto-recovery, here's the change. In file ultralcd.cpp, look for...

#ifdef ULTIPANEL
static void lcd_return_to_status()
{
      encoderPosition = 0;
      currentMenu = lcd_status_screen;
}

and add one line to it...

#ifdef ULTIPANEL
static void lcd_return_to_status()
{
      encoderPosition = 0;
      currentMenu = lcd_status_screen;
      lcd_implementation_init();    // added; reinitialize the display module to recover from garbled display mode if happening
}

The lcd_implementation_init function already exists. It calls the lcd.begin Arduino LiquidCrystal library function that takes care of initializing the display module. It also sets up a handful of custom character bitmaps like the thermometer symbol, and then it clears the display. I found that just calling lcd.begin would sometimes leave the custom character bitmaps incorrect, so I ended up adding the full init. The only time this additional code is executed is when the LCD display is about to return to the top status screen. The change won't be incorporated unless your configuration.h file invokes the #define for ULTIPANEL.

FOLLOWUP COMMENT: Looking into the LCD code some more, I see the same lcd_implementation_init is already included as part of software detecting SD card insertion and removal. That code even has a comment with it that talks about how it is an attempt to recover the display from a possible static discharge. So, for a printer standing around doing nothing, just inserting or removing the SD card will also reinitialize the display module, without having to make this change.

[JimG]

Sorry to bring up an old thread. But I'd like to know how well this fix has worked?I've been fighting this problem for years on other projects.Jim

[printbus]

Sorry to bring up an old thread. But I'd like to know how well this fix has worked?I've been fighting this problem for years on other projects.Jim

I've used the trick maybe twice to recover from a garbled screen since I made the firmware change. Although the screen isn't readable when it occurs, I just hit the button on the smart panel and let Marlin time out and return to the main menu to reinitialize the display interface. I haven't described it in my MakerFarm i3v build thread yet, but I've also added a bezel over the LCD. I learned in other projects a long time ago that having these type of LCDs behind a bezel can do wonders in protecting them from going nuts after inadvertent static discharge.

As I update other projects using the LCDs in 4-bit transfer mode, I'll be looking for ways that I can automatically do the interface reinitialization periodically now that I understand how the data nibbles can get out of sync.

[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.

[ESS]

I don't really think that the screen get garbled due to timings or ESD.
I never supposed that anybody could connect something directly to an MCU pin with a half-meter wire, but they did it... And that single thin GND wire (yep, only one of 20 wires is a GND) only aggravates the situation.

This garbling issue can be fixed by adding a serial resistor to each MCU output connected to the LCD. These resistors should be placed as close as possible to the signal source (i.e. to the MCU in our case case) and by routing a reliable ground wire to the LCD board.

But I'm to lazy to do all these things, so I've just cut the LCD cable (there are two cables - one for LCD and power, and another one for SD card) at the mainboard side and solder 47 Ohm resistors there. This appears to be enough to get rid of LCD screen garbling.
lcd1.jpg

[printbus]

This garbling issue can be fixed by adding a serial resistor to each MCU output connected to the LCD. These resistors should be placed as close as possible to the signal source (i.e. to the MCU in our case case) and by routing a reliable ground wire to the LCD board.

Interesting. Be sure to report back after a while to confirm whether or not the series termination resistors solved your garbled display problem. I'd try the fix myself, but I've eliminated the nibble transfer display as part of migrating to Smoothieboard on my i3v.

Technically, the bulk of the benefit is likely obtained by adding the termination resistor in the E signal line to the display. IIRC, that is the signal that is pulsed to latch each nibble data transfer into the display module. Ringing on any other pins likely wouldn't matter as long as they're stable when the E pin is pulsed, but there's no reason the termination can't be added in all the data lines. Also note that some of the data lines (encoder, SD reader) on the two cables are driven by the smartpanel and not the ATMEGA2560.

I don't really think that the screen get garbled due to timings or ESD.

While ESD may not be the cause in all cases, it definitely played a role on my printer. I'd occasionally see the printer garble the display all by itself, but most of the time it would happen when I'd reach for the knob - especially if a finger wrapped around the panel and touched one of the smartpanel circuit boards. EDIT: And BTW, the Marlin code change mentioned in post #18 even has a comment associated with it that says the change is an attempt to recover from a static hit...