DOGLCD/Full Graphic Smart Controller issues

[bladykast]

I wanted to try to swap LCDs to use a bigger 128x64 display on my Prusa i3 MK2. Considering it was Marlin firmware, I thought it would just be commenting and uncommenting a few lines. However, it seems like Prusa has not kept up with their firmware and left dogm_implementation.h incomplete.

I am using the http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller display. Whenever I try to compile the 3.0.10 firmware for my printer, I get errors related to different functions not being implemented. I looked at #71 and found that the file was incomplete compared to ultralcd_implementation_hitachi_HD44780.h. So, I modified the firmware files to include the excluded methods to make the firmware compile.

Even then, I am still plagued with issues. Almost every single instance in the configuration files returns:

C:\Users\3s\AppData\Local\Temp\arduino_build_762328\sketch\ultralcd.cpp: In function 'void lcd_change_filament()':

ultralcd.cpp:965: error: 'lcd' was not declared in this scope

   lcd.setCursor(0, 1);

   ^

And

C:\Users\3s\AppData\Local\Temp\arduino_build_762328\sketch\dogm_lcd_implementation.h: In function 'void lcd_implementation_drawmenu_generic_RAM(uint8_t, const char*, char, char)':

dogm_lcd_implementation.h:507: error: 'lcd' was not declared in this scope

     lcd.setCursor(0, row);

     ^

Log is attached.

However... if I comment out

define DOGLCD

it uses ultralcd_implementation_hitachi_HD44780.h. It compiles correctly, but nothing shows up on the display, nor do any buttons work. Standard Marlin 1.1.1 will compile just fine with the smart controller, but the Prusa custom firmware will not.

Is there anything I'm missing now? Any configuration options I can use to get this working?

[das300hub]

Please read issue #71 i added stuff there about potential solutions . My experience is limited with marlin and prusa so i am still on a learning curve regarding hardware software details . Are you saying the prusa software is vers 3.1.10 and that it is a marlin modified code? Assuming this that means the mini rambo must be identical to rambo and mega ? We would need to establish this and then detail the code required and or hardware modifications to be made .

[bladykast]

@das300hub Prusa software currently is version 3.0.10. Prusa's current firmware is a much older fork of Marlin firmware. Marlin FW is 100% compatible with DOGLCD and 12864 displays: HOWEVER, Prusa's older version is completely incompatible with the display because the code implementation is seemingly broken.

Hardware-wise, the mini-RAMBo and LCDs are all compatible. Nothing is electrically wrong with the setup as they all use the standard 10-pin LCD ribbon connectors. Furthermore, they are already well defined in the firmware.

Summary: Basically, the hardware is perfectly fine, it's just the code (specifically, the LCD implementation) that is broken with Prusa's firmware.

[bladykast]

Here's what I think the issue is...

Since idk if anyone has ever used a DOGLCD/GLCD with an i3 MK2 before, I just don't think the code has ever been checked in their firmware with regards to this specific LCD. It hasn't been updated since whenever the fork was created [~year ago]. You can see the Hitachi HD44780 controller implementation has been constantly updated (that's the one used on the basic 20x4 character LCDs that ship with the i3 MK2). However, the ST7920 implementation (used on the RepRapDiscount GLCD/DOGLCD/12864 LCDs) hasn't been updated (or even checked, I'd believe) since the fork's release.

Another thing is that the HD44780 uses the LiquidCrystal libraries, while the ST7920 uses the u8glib libraries (guess which ones aren't ever used on the stock firmware...)

I've already tried hacking together Marlin firmware revisions, both old (didn't work) and new (really didn't work). It'd be way too much time for me to delve into this, but I just believe the Prusa fork is so far off the new Marlin releases that the only thing we can hope for is for the developers to try to fix this somehow, or wait for them to rebase their code with Marlin 1.1.x (possible? maybe?).

@michalprusa | @PavelSindler | @bubnikv or whoever can give a definite answer, is this the case with the Prusa firmware? And is there any possible way to get these displays working?

I personally want to try digging deeper and anything short of completely porting everything over to the new Marlin FW...

Thanks

[Swiftnesses]

Surely Prusa are due to sync with the main branch soon? They've also added a bunch of awesome new features!

[das300hub]

So should we invest in solving this problem or wait for the upgrade ? Is it possible to get an idea of if this issue is being considered ? It seems that it may not be an exhaustive problem to solve for people already programming this software .

[das300hub]

@bladykast When you compiled the marlin did you successfully test the lcd worked with minirambo unit?

[bladykast]

@das300hub LCD did work on stock Marlin 1.1.x with the mini RAMBo.

[das300hub]

Assuming a prusa mkll ,single filament .

So the question is what features in prusa software are invaluable in comparision to marlin?

• digitisation of heatbed ? What else ?

[das300hub]

UPDATE-

• I decided to test my MiniRambo :+1:
• 1) as operational
• 2) that miniRambo can operate Full Graphic LCD 128 x 64
• 3) miniRambo can run Marlin.

Process - In order for the miniRambo to operate in Marlin 1.1.x , Arduino had to be loaded and the Rambo board add-on installed with arduino board manager. Once this is done we select RAMBO as the source board and can load the Marlin latest software into Arduino IDE program and compile it to the miniRambo.

The Marlin software was adjusted in Configuration.H for full LCD and adjusted to select type as miniRambo.

This process ran smoothly and showed that 1) , 2) ,3) above all operate correctly. The miniRambo operates fine in Marlin.

Conclusion - The Prusa Is very capable of using Full graphic LCD ( ignoring memory limitations). There appears no hardware limitations in the miniRambo. Upgrading to a Prusa MK2 currently requires a 128 x 2 graphic controller to make Prusa functional due to calibration process only possible in LCD.

[wwlgray]

I have the 3.1.1 version of the MK2 firmware compiling with the 128x64 uncommented, the problem is that the sqketch is a little over 1kb too big. Still trying to trim it, but it may take a while.

Edit: Well I got it. I had to take out Flashair and multi-material support, but I did get it to compile. Tomorrow is testing day.

[thess]

You can try trimming languages - you'll need at least 2 due to a bug in the Perl script.

[wwlgray]

I took out all the languages and got it to compile. I put it on the test machine and I could see the lcd and writing on it, but it was garbled. It looks like the code is hard coded to a smaller size. I will have a look tomorrow as it is 9 PM here now.

[bladykast]

Thank you so much for revisiting this!! My screen has been sitting in the box for 6 months waiting for there to be progress on Prusa's side. Please let me know if you need a mule for testing

[wwlgray]

Once I get it working, It will be without Multimaterial, but I will let it out in the wild. I have about 5 screens just sitting and waiting. I also want to be able to use the skew correction with the Orballo, MK42 clone heatbeds on my home built machines.

[Agniusm]

I thought the light at the end of a tunnel went out on this. I have 2.4 lied sitting. Eould be great to get it working. Taking out the languages is a good move.

[boelle]

anyone got more success with this? even just 2/4 lines of text on the graphic lcd would be a bonus

[bladykast]

@boelle Since #71 and #100 are still open, and the repo is currently at issue # 1017 and about 350 open issues... fat chance this will ever get fixed. Prusa doesn't seem keen on fixing this issue since it doesn't affect them at all.

[boelle]

i know.... i wish some of the features would be ported to marlin (as marlin have the full lcd)

i guess 2 of the biggest things would be the selftesting and support for the mk42 bed and maybe an option to have marlin tell how crooked the bed is and give the user a chance to correct the hardware before the firmware "levels" and "correct" things

i would have done it if i where a coder

[JoePrints]

It is not in PR firmware because there is not enough memory to support all the characters/graphics along with the XYZ calibration, mesh bed leveling....etc

[3d-gussner]

@bladykast We have limited resources and will not add this to the Prusa-Firmware. Please close this. [stale][wontfix]

[JohnnyDeer]

I'm closing this issue as stale, thanks for understanding.