RepRapDiscount Full Graphic Smart Controller not working properly.

[borys-wwa]

Hi. I am about to migrate my ANET A8 to RAMPS 1.4 and I am doing some testing now and I am experiencing a strange issue with the RepRapDiscount Full Graphic Smart Controller. The issue is the same (as well as the LCD display model) as the one described in , this YouTube video however solutions provided there do not work for me. The issue occurs on Marlin 1.0.2-2 as well as 1.1.0-RC8. What is interesting about it, that when I followed the test described in this YouTube video which basically executes u8glib examples on the LCD which is connected to Arduino Mega board through a RAMPS 1.4 shield, then everything worked fine. I could see graphics, also without any garbage (more on that later). When I then reflashed Arduino with Marlin, LCD suddenly started working as expected (except for garbage - more on that below :) ). It worked well until I disconnected the power. Then again - same symptom as on the first YouTube video quoted in this post. After flashing with the u8glib example - exmaple is working properly. And again - after flashing back to Marlin - LCD is also working properly with Marlin, until power is disconnected. Could it be possilble , that LCD is for some reason not being "initilaized" correctly by Marlin and therefore does not work, until it's properly initialized by the u8glib example (which works until power off)?

Could this have something to do with this random garbage presented on the LCD when using Marlin? (there is no garbage when using the u8glib examples). I found the solution in one of the other posts about commenting "#pragma GCC optimize (3)" line in ultralcd_st7920_u8glib_rrd.h. This worked well and the garbage dissapeared, at least mostly. It reappeared, but in significanly smaller magnitude, when I heated the RAMPS 1.4 and Arduino board with a hair dryer (I was looking for cold solders). The garbage didn't occur on the u8glib examples, which suggests that there is something specific in Marlin, that is causing it. It seems that there might be some communication issue (maybe timing is off or communication is distrupted by some other work CPU is doing for Marlin / interrupts? or some interference ?) Maybe that is why LCD is not being initialized properly with Marlin.

I have tried this on Arduino IDE 1.8,2 as well as 1.0.6. I am using the latest u8glib (1.14). In IDE 1.0.6, I also needed to apply solution from this post , to have the 1.0.2-2 firmware complied properly (1.1.0-RC8 complied without issues on 1.8.2).

Here is my configuration.h for 1.0.2-2 And here is configuration_adv.h This is just a test setup for now as I'm only testing it offline to ensure that it works before I upgrade my Anet A8 to Ramps 1.4, so the config files may look a bit strange when it comes to the hardware setup.

Thank You in advance for any support on that.

Kind Regards, Darek.

[Angel996]

To try to isolate the problem, for once, try using shorter cables. I've had lots of problems because of longer cables both with standard and full graphics discount controllers. The chip on the LCD PCB could be faulty too. It happens.

It was already noted that these LCDs have 4-bit and 8-bit modes. For some reason, developers of these boards decided to use 4-bit mode, which takes less data pins, but is much less stable. And that's the root of all problems. I've tried everything, putting additional caps on power lines: nothing helped. Only shortening the data cables did. BTW, to get it back from "garbled" state, usually a push on the menu button is enough.

Also, creators of this board for some reason decided to power the backlight from the +5v source. Which makes it shine thru the room at night. I modified it to use +12v source with the help of a 4k7 resistor. If you are a student and you sleep in the same room, for instance, that's a great hack.

[borys-wwa]

Hi. Thank You for a quick reply. I will get shorter cables today and see if that helps, but in the meantime - I am wondering, why does the cable lenght not affect the examples from the u8glib, the same way it does for Marlin? As for the garbled state - before applying the fix mentioned earlier (commenting out the #pragma GCC optimize (3) ), Nothing seemed to helped. whatever I didn, the screen was garbled and barely readible. However after this fix, there are no artifacts at all (unless I heat up the whole board as mentioned), but I woldn't bother about that as much as for the fact that after power down, screen stops working complately, which makes it rather useless :) And yes - I can see how screen backlight can be a problem :) fortunately I have the liberty of havig the 3D printer in a separate room so that issue won't be as critical for me :)

[Angel996]

For an easy way: you can just move the connector from the end of the cable to it's middle. They are reclamped easily. Only need to be careful not to break the connectors while unclamping.

I don't know much about u8glib, but it could be about the data transfer rate. Since u8glib has a lot of time to spare, it probably uses a lower sync rate than Marlin. Marlin, on the other hand, is a real time application, it has to run very fast to ensure it's main work is done.

BTW, I have both simple and full graphics controllers. They say, full graphics version makes Marlin run much slower because it has to transmit data in graphics form, whereas simple controller accepts it in character code mode. I ordered the full graphics version out of curiosity, but I can tell it offers NO advantages over the character version, in reality. :) There are no graphs to draw, its 100% text information. :)

[FHeilmann]

~~What I had on my board was that the connector for both ribbon cables were reversed on the display board (i was getting periodic silent beeps while it was switched on, backlight yes but nothing else). Try to google it, maybe your connectors are flipped as well. If it is, you'll have to force it in or make a cut-out for the connector to fit reversed on the display controller..~~

nvm. the u8glib examples seem to be working so its most likely not a connector orientation issue

[Angel996]

Actually, AUX-1 is used for the LCD. AUX-2 is used for SD card and encoder. LCD will run without it.

[Bob-the-Kuhn]

RCBugFix has much improved LCD speed since RC8 plus some LCD bug fixes. Switching to RCBugFix is highly recommended. Unfortunately you can't just drop your config files into RCBugFix.

I'm using the U8g2 library. I tried u8glib 4-6 months ago and had problems.

Interesting - u8glib is back. Maybe it's always installed with the newer Arduino IDE releases.

[Angel996]

I am sorry, but I am using RCBugFix on 3 Marlin devices and I have not noticed any improvements over LCD performance. It still goes "garbage" from time to time, esp. if you use just a slightly longer cables. I don't think anything can really be done to overcome 4-bit mode side effects. Other than just using some routine that would reset the LCD from time to time. Actually, maybe, that's what Marlin should have as an option in config file? Like, "enable this if you experience LCD screen being garbled" ?

[ghost]

If your cables are longer than normal, shield them or get shielded cables. That will reduce the effects of interference.

[Angel996]

It's not external interference, it's simply signal loss. Which means, with longer cables, TTL levels may be misinterpreted or obtain parasite oscillations from the cable itself. In my experience, putting 1k pullups both to +5v and GND might help in such cases. Or using thicker GND line. Or separate GND line for each data line, like in HDD IDE cables.

[benlye]

Apologies if this isn't helpful, but is it a timing thing?

I also have an Anet A8, but am using the Anet A6 version of the RepRapDiscount Full Graphic Smart Controller. I found that without these delay definitions I get garbage on the screen right from power-on. The screen is just about readable, just very garbled.

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

So I'm trying to understand exactly what these lines do.

(The definitions were in the pins file that is commonly used for the Anet board, and I was/am trying to understand why.)

[borys-wwa]

Ok. I finally found some time to work on this. So I have shortened the cables to less than 5 cm and there is no difference as compared to the long cables. Marlin 1.0.2-2 on IDE 1.8.2 - after power on - blank screen. Beeps, it seems that the controller is working, but nothing is being displayed. Uploaded GraphicsTest - all works well. Reuploaded Marlin - everything is ok, no garbage, as long as the "#pragma GCC optimize (3)" is commented out. After uncommenting it - significant ammount of garbage shows again, same as compared to long cables, so it's most likely not an interference, but timing issue.

The biggest question now is why LCD does not work on Marlin after shutting the power down. Again - it seems like Marlin is not initializing the LCD properly.

I did another test - I have uploaded the GraphicsTest. It started showing the example data and then I disconnected the LCD from the board and reconnected it back again without powering the board down (so the example was running whilie I was doing it). After reconnecting LCD to the board I got the same blank screen as on Marlin again - suggesting that the screen can't work without being properly initialized by the software after powring down (I assume that the initialization happens only once at the beginning of the code of that u8glib example, so when I reconnected the screen to the board that was already running the code. the screen wasn't reinitialized after powering off and hence - the blank screen, even though Arduino is for sure sending signals to it to display the examplary graphics).

I will analyze the GraphicsTest code to see if I can find how the screen is being initialized.

Angel996 - thanks for the information on the Marlin performance with the graphics LCD. I wasn't aware of that. I will consider getting a text LCD if that is supposed to improve the experience, however for now I want to get the Graphics LCD working.

[borys-wwa]

I made it work by commenting line 79 (U8GLIB_ST7920_128X64_RRD u8g(0);) in dogm_lcd_implementation.h and adding following line below it (this is taken from this YouTube video already mentioned in my first post). U8GLIB_ST7920_128X64_1X u8g(23, 17, 16); // SPI Com: SCK = en = 23, MOSI = rw = 17, CS = di = 16

I assume that is the initialization routine and I simply substituted the original Marlin one with the one from the u8glib example with pin descriptions as discovered by the aforementioned YouTube video creator. Questions now are: 1) is this the right approach? 2) why did the original Marlin init routine not initialize LCD properly?

[Bob-the-Kuhn]

@borys-wwa - please post the configuration files you are using with RCBugFix.

@Angel996 - the only schematic I could find for the RepRap Discount Full Graphic Smart Controller shows it in serial mode. Could you point me to the 4 bit documentation?

[ghost]

It's not external interference, it's simply signal loss. Which means, with longer cables, TTL levels may be misinterpreted or obtain parasite oscillations from the cable itself. In my experience, putting 1k pullups both to +5v and GND might help in such cases. Or using thicker GND line. Or separate GND line for each data line, like in HDD IDE cables.

Ok. Mine was fixed by shielding the cables. I had made ~28" cables for my display to sit in front of the printer slightly below the bed level. I had random weird artifacts and unreadability before shielding the cables. I did not install any resistors. I do not have anything special set in Marlin. I am using u8glib. I have not had any issues with the LCD in the last year.

Also, everything still runs just fine despite the low memory (UBL enabled).

Sketch uses 189808 bytes (74%) of program storage space. Maximum is 253952 bytes.
Global variables use 7009 bytes (85%) of dynamic memory, leaving 1183 bytes for local variables. Maximum is 8192 bytes.
Low memory available, stability problems may occur.

[borys-wwa]

@Bob-the-Kuhn - Here is my 1.1.0-RC8 configuration.h and configuration_adv.h Again - it only works after using the GraphicsExample from the u8glib examples library to initialize the LCD properly (otherwise it just shows blank screen). On 5 cm cable it shows a lot of garbage as seen on video below: Video 1 In this case ( for RC8) commenting the "#pragma GCC optimize (3)" line in ultralcd_st7920_u8glib_rrd.h does not seem to help at all.

[Bob-the-Kuhn]

@borys-wwa - I didn't see anything strange in your configuration files.

Please try RCBugFix. To make it as painless as possible I've translated your config files. There were very few changes that needed to be copied over. The translated files are here. You should be able to just download the new firmware, drop these two files into the directory and then upload to your controller.

I saw your video. Slow update with garbage. I don't see how you could make the cables any shorter.

Have you measured the power ON the LCD? It should be 4.75V or more.

You should also measure the voltage differential between ground ON THE RAMPS CARD and ground on the LCD. It should be under 0.1V

[borys-wwa]

I have uploaded the RCBugFix without any issues and have included the config files from You. LCD is now working also after power off (I disconnected power complately instead of reseting the board, and it remained blank :( ) however there is still a lot of garbage. I would say it's very simillar to what You could saw in that video I posted in my last post

~~I will check the voltages and let You know immediatelly after I find out where I can find + and - on that LCD board while it's connected to the RAMPS and working :) ~~

Power on LCD board is +5.07 V Differential between LCD ground and RAMPS ground is 0,002 , which basically is the same what my multimeter shows when not being connected to anything so we can assume that it's negligeable.

So, with the new Marlin versions there are still two issues (RC8 as well as RCBugFix): 1) LCD does not initialize properly after powering down 2) garbage on the LCD which is not possible to solve using the solution that works for the 1.0.2-2 version.

[Bob-the-Kuhn]

I think it's time to sprinkle 180 proof holy water on it & sacrifice it to the gods.

By chance are you running a really old version of u8glib? Arduino keeps asking me to update libraries and my Arduino's u8glib is version 1.19.1

[borys-wwa]

:) I still hope a better solution can be found :) As for the u8glib version - I wrote in my first post, that it's 1.14, but I am not sure if that is correct, to be honest. I'm quite new to Arduino and I followed on eof the guide's I found on how to install that library (I can't find that guide now). That guide pointed to the "latest" 1.14 version, which I downloaded as a zip and added to the Arduino IDE. However now I can see that my Arduino has version 1.19.1 installed (Sketch > Include Library > Manage Libraries). I'm not sure, which one is it using then... the one I installed manually, or the one which Aruino states it has installed... while troubleshooting this issue, I have installed and uninstalled and reinstalled numerous versions of Arduino IDE, so I'm not really sure if that installation of u8glib 1.14 I did at the very beginning is still there. Is there any way to see which U8glib.h is being used when my sketch is complied?

Also - I am wondering if the issues I'm facing could have something to do with the Arduino board I'm having. It is supposed to be original Arduino Mega, but maybe the processors clock is slightly off and that is causing the issues (however I believe that USB communication would have been affected even more in such case). Anyway - I have few Arduino Mega clones laying around - I will try to switch those and see if this helps. Otherwise, I need to stick to the 1.0.2-2 and the fixes I mentioned earlier as that is the only option working for me now.

Thanks for the will to help anyway :)

[ghost]

FYI: I am running u8glib 1.19.1

[psavva]

@borys-wwa can you confirm if this issue is resolved? If so, can you close this ticket?

[borys-wwa]

Well. I found a workaround for my specofic issue, but I'm not sure if this is a good solution or not and what could be the potential side effects of it. I thought that it might be a good information for anyone that might want to reuse this workaround for simillar issue. I also think that it might be good for someone to compare this workaround with Marlin original and see if Marlin original can be somehow updated to work with this LCD, as, aparently - it's posible :)

If I am mistaken, then let me know - I will then close this incident.

Here is the workaround:

I made it work by commenting line 79 (U8GLIB_ST7920_128X64_RRD u8g(0);) in dogm_lcd_implementation.h and adding following line below it (this is taken from this YouTube video already mentioned in my first post). U8GLIB_ST7920_128X64_1X u8g(23, 17, 16); // SPI Com: SCK = en = 23, MOSI = rw = 17, CS = di = 16

[psavva]

Here is the table on how he mapped the pins. http://zeepromarket.com/pdf/ZEE%20Ard-Ramps14-LCD-JHD12864F.jpg

Perhaps it's specific to some RRD LCDs that use a different controller on the panels?

[borys-wwa]

I took a look at this and focused harwdare side, meaning the clock, data and cable select SPI pins (CLK/MOSI/CS), which are directly provided in the initialization procedure that has made LCD to work (23 - Clock, 17 - Data, 16 - Cable Select). I checked the pins.h for possible issues in pin definition, but had found none. I then substituted the line from the workaround: U8GLIB_ST7920_128X64_1X u8g(23, 17, 16); // SPI Com: SCK = en = 23, MOSI = rw = 17, CS = di = 16

with line like below, to use the same init procedure from u8glib example, but using pin definitions from pins.h (same, as being used by the Marlin LCD procedures from ultralcd_st7920_u8glib_rrd.h): U8GLIB_ST7920_128X64_1X u8g(ST7920_CLK_PIN, ST7920_DAT_PIN, ST7920_CS_PIN); using Marlin pin definitions rather then directly specifying those, and after this change, LCD still worked as expected (even after power off), which suggests, that pins are properly defined in pins.h for that LCD. This suggests, that it's not a hardware problem, but software, and leads us to the Marlin LCD initialization procedure, as Marlin seems to be able to display data on the screen properly, but only after it is initialized by another software or function from u8glib.. As mentioned above - this Marlin function (u8g_dev_rrd_st7920_128x64_fn) uses the same pin definitions as used above (which worked with the u8glib init proc), but despite that - it doesn't work properly, so, again, it does not seem to be a pin definition/assignment/hardware issue.

I assume that this Marlin LCD procedure was written for a purpose (otherwise the one from u8glib would be used - I assume that a performance optimization was the cause of rewritting it), so I would still prefer to use that improved one, but for now, it's not possible.

Perhaps, as You mention, my LCD screan uses a different hardware controller, which has a different command set, but I doubt that.

I will continue investigation of the original u8glib.h library to see if I can find anything obvious, but perhaps someone is more familiar with Marlin LCD implementation and would be able to troubleshoot this quicker than I can?

Any help would be highly apreciated.

[SimGas]

Hi. I know this topic is pretty old, but I guess I found a solution for the problem. I was facing exactly the same garbage display on the RRD Full Graphics Smart Controller using a PICA board from mjrice.

He came up with the idea of turning off the code optimization in ultralcd_st7920_u8glib_rrd.h Line 40: `//set optimization so ARDUINO optimizes this file

pragma GCC optimize (3)`

I just commented out the #pragma command and now it works fine 👍

Source: reprapwilson.discoursehosting.net

[thinkyhead]

@SimGas — Had you already tried increasing the delay settings? For example…

  #define ST7920_DELAY_1 DELAY_3_NOP
  #define ST7920_DELAY_2 DELAY_3_NOP
  #define ST7920_DELAY_3 DELAY_3_NOP

Larger delays are more reliable but also slow down SPI communication with the display.

[elliotboney]

Just wanted to thank @SimGas because I have had this issue for over a year now, and your tip fixed my display on my Anet A8! Thank you so much!

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