Marlin: LCD Garbage Data

[nsiatras]

Hello,

I recently purchased a RepRapDiscount full graphics smart controller (128x64 LCD Screen).
After uploading the Marlin 1.1.0-RC8 Firmware to the Arduino I noticed that the LCD starts to display garbage data or showing data to wrong position after a while.

Here is a photo to see what I mean http://imgur.com/a/sOGPv

This problem stops if I power off the 3d printer and then power it on. I tried the following to fix that issue but I had no Luck.

"Solutions" tried so far:
1) I bought a new RepRapDiscount full graphics smart controller
2) I changed the LCD cables and the RAMPS 1.4 LCD adapter
3) I shielded the LCD wires with aluminum tape

Is it possible to be a software Issue ?

Thank you

[Fulg]

I have the same issue when using a Viki2 LCD on an Azteeg X3. At the time I suspected my cabling since I had to make an adapter to use it, but I didn't investigate further...

Did it work for you before 1.10-RC8?

[ghost]

Here we go again... Search for LCD and you'll find out why.

[ghost]

Alumuminum foil or tape is good, but you have to drain the shield.

[nsiatras]

Well... It is not an issue with the cabling. I see garbage data even if the controller is just plugged in on the USB on my desk without any motors and fans near or attached to it.

[nsiatras]

You believe is a faulty RAMPS shield?

[Fulg]

I believe @Tannoo is referring to #5542, #5703 and #5720. Since I have the same issue on a different kind of LCD (and that LCD works perfectly with Smoothieware), I think this confirms a cabling issue.

Still, I find it interesting that many are suddenly having the same issues. I will have to try again with an earlier release (for example before #5389). Maybe the LCD update is more susceptible to interference now that it is spread out.

[nsiatras]

I read all the other issues related to the LCD garbage data and I finally managed to fix my problem.

I defined the following set of delays (0,2,0) in the ultralcd_st7920_u8glib_rrd.h file and everything works like it should :)

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_2_NOP
#define ST7920_DELAY_3 DELAY_0_NOP

Thank you for your help everyone

[nsiatras]

Even with the changes I made to the ultralcd_st7920_u8glib_rrd.h the garbage data returned after a few hours with the machine idle.

I installed another open source firmware last night and after 8 hours of printing the LCD works great. So I guess that the issue has nothing to do with the LCD cables or my hardware.

[ghost]

That is odd. You see, I have had no issues with my LCD with Marlin 1.0.?, RC6, RC7, RC7-RCBugFix, RC8, and RC8-RCBugFix. Still running strong and is powered on about 99% of the last year.

I have custom length shielded cables I made (~26" long). Still no issues. I don't see it being a Marlin issue.

Maybe there was a bad copy or bad upload?

I have been flashing like crazy in the last few months. I am more expecting my Arduino to crap out before I expect any issues with the LCD.

Just my 2 cents.

[ghost]

I am willing to help, but I cannot get my LCD to produce that issue, so I have nowhere to look.

[ghost]

I do not have those delays defined in my setup.

[Fulg]

FYI I also believe this is a cabling issue. This is a semi-random issue so it is hard to diagnose. From what I've seen, sometimes even the Marlin boot logo is corrupted, other times it takes several hours for the display to start becoming corrupted.

[nsiatras]

I believe that my issue with the ReprapDiscount LCD has to do with a "discount" the Chinese manufacturers have done on their PCB manufacturing process. As @Fulg said it is a random issue and I can tell that none of us can reproduce it.

[Fulg]

I can see the issue on a Viki2 LCD, which is definitely not of the "discount" kind. :) However it uses the same display protocol as the RRD FullGraphics LCD. I believe there is some interference on the SPI lines which corrupts the display.

[Blue-Marlin]

If you can't get it to work stable with

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_2_NOP
#define ST7920_DELAY_3 DELAY_0_NOP

try even longer delays.
If that does not work you might have activated

  // Enable this option and reduce the value to optimize screen updates.
  // The normal delay is 10µs. Use the lowest value that still gives a reliable display.
  //#define DOGM_SPI_DELAY_US 5

`This can also be used for delays longer then 10µs - if you need it.

All above is only valid for REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. That's the only one using our own display driver.

@Fulg
VIKI2 uses the stock u8glib driver. Blame u8glib, or your particular display, or your particular board, or your too long cables, or a too noisy environment,. or ... - but not Marlins ST7920 device - that is not used for a VIKI2.

[Blue-Marlin]

For the much faster 32bit processors it might make sense to use the stock u8glib device - else in our ST7920 device the number of NOPs will grow huge - which it's not prepared for.

[Fulg]

@Blue-Marlin At no point did I blame software :) As I said since the beginning, I think this is a cabling issue, most likely from unshielded wires or defective connection adapter. The fact that the same problem happens on Viki2 and RRD FullGraphics, despite them using completely different display drivers, seems to further confirm this.

The only weird data point is @nsiatras who said that by switching to "another open-source firmware" (presumably Repetier) also solved the issue. That and the fact that this garbage LCD problem keeps being reported lately.

[thinkyhead]

It's probably exacerbated by display optimizations in the latest Marlin, which attempts to save cycles by using smallest-possible delays between signals. The settings noted by @Blue-Marlin may be increased to get a more reliable (but also less optimal) display. Higher-quality cables may also fix the issue.

@nsiatras who said that by switching to "another open-source firmware" (presumably Repetier) also solved the issue.

Of course @nsiatras has only tested a graphical display, which _does_ depend on the settings noted and is more susceptible to the optimizations they represent.

[nsiatras]

@thinkyhead Actually I tested 2 LCD screens with 2 sets of wires and 2 RAMPS adapters and I shielded all wires with aluminum tape.

[ghost]

Ground the aluminum tape at one end to earth ground.

[thinkyhead]

@nsiatras And did you also adjust the various timing settings that were pointed out above?

[nsiatras]

@thinkyhead Yes I tried to adjust that

[Fulg]

For what it's worth, I had the same issue on a second printer (Azteeg X3 and RRD Full Graphic Controller). Using the delays suggested by @Blue-Marlin fixed it, but I had to increase them further to get a stable output.

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_4_NOP
#define ST7920_DELAY_3 DELAY_0_NOP

[shacal]

define ST7920_DELAY_1 DELAY_0_NOP

define ST7920_DELAY_2 DELAY_1_NOP

define ST7920_DELAY_3 DELAY_2_NOP

Has been most stable one.

DELAY_4_NOP is a bit much in one place.

[vontemp]

For Fulg, how did you wire the RRD Full Graphic Controller to the Azteeg X3. I am looking to reprise my desire to build a CNC and I have this board from a previous effort.
Regards

[Fulg]

@vontemp I made my own adapter board, converting from the RAMPS adapter to a couple of X3 wire looms to the various EXP ports of the X3. It is not pretty but works well enough. I did not bother with the SD card reader.

You need to make changes to pins_AZTEEG_X3.h to make it work, something similar to this:

//
// LCD / Controller
//
#if ENABLED(VIKI2) || ENABLED(miniVIKI)

  #undef DOGLCD_A0
  #undef DOGLCD_CS
  #undef BTN_ENC
  #define DOGLCD_A0         31
  #define DOGLCD_CS         32
  #define BTN_ENC           12

  #undef STAT_LED_RED_PIN
  #undef STAT_LED_BLUE_PIN
  #define STAT_LED_RED_PIN  64
  #define STAT_LED_BLUE_PIN 63

#else

  #undef DOGLCD_CS
  #undef BTN_EN1
  #undef BTN_EN2
  #undef BTN_ENC
  #undef SD_DETECT_PIN
  #undef LCD_PINS_RS
  #undef LCD_PINS_ENABLE
  #undef LCD_PINS_D4
  #undef LCD_SDSS

  #define LCD_PINS_RS       31
  #define LCD_PINS_ENABLE   32
  #define LCD_PINS_D4       39

  #define BTN_EN1           22
  #define BTN_EN2            7
  #define BTN_ENC           12
  #define SD_DETECT_PIN     49
  #define LCD_SDSS          53

#endif

Combine this with the X3 wiring diagram and the RAMPS connector board to see what goes where, and with some patience you can make it work too.

Honestly though, if you have an X3 I highly recommend using the Viki2 or the Mini-Viki instead, the form factor is much nicer (and so is the display).

Good luck!

[161at134]

Moved ribbon cable away from other wires, installed flat ferrite core on ribbon close to LCD. So far works good.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.