Hybridizing the Wanhao Printer (generic mainboard)

I found this project quite by accident, while trying to find whitepapers on the LCD. Great stuff!

I loved my IIIP (literally) to death. In particular, the death of at least one of the stepper drivers, but not after spooling at least 10kg of filament.

I have no interest in reviving the old mainboard. Instead, I’m gutting my IIIP and turning it into a more-or-less reference Marlin/RepRap with dual extruders and a Zprobe.

I’m doing this with a generic RAMPS 1.4 board with replaceable (yay!) stepper drivers and running Marlin.

At the start of the project a few days ago, I was content to make this a dead-headed printer running directly off one of my old spare PCs, so while I was poking around to see if it was workable, I weally wasn’t bothered about it since I could always deadhead it through a USB port…

But then I found this LCD this so-called Sebastien Andrivet came up with. Absolutely stellar stuff. Must have it.

I’ve done some rooting around in the forums, and to my disbelief (having blown out 2 of these boards already just using them) it doesn’t look like doing this has ever occurred to anyone–or else I’m searching the wrong terms.

In any case, my understanding as to how the LCD works is that it essentially feeds the mainboard serial commands, based on standard Marlin commands and expected responses. This would imply that as long as I can sort out the physical interface with the RAMPS board, then all I really need to do is make sure that the pre-built config/tuning scripts are using the correct calls/responses.

I’m in the planning phase while I wait for Amazon to Nerd Up my mailbox with stacks of electronics components… Any advice or direction would be nice–especially if someone has already invented this particular wheel.

Sorry, but this is wrong, especially “based on standard Marlin commands”. It has nothing in common with Marlin commands. Those LCD panels are used in many different devices, not 3D printers in particular.

It is a plain, regular serial interface.

It does not work this way. There is no such scripts.

Some people have already made something like that, based on my code but as far as I know, it was never published publicly. There is also some code inside Marlin itself (not based on my code, but based on my documents). But unfortunately, it is really not easy to use and understand. The LCD panel themselves are documented, but for this particular model, it is only in Chinese.

Nope–no sorry needed. This is how we learn :slight_smile:

I realize I’m being basic in my descriptions, and focused purely on the top-level and bottom level functionality of the LCD screen in my question. I understand (or at least think I do) the relationship between the mainboard, the LCD, and the middleware on both arbitrating the whole mess. MY understanding of the fundamental problem is that the Marlin firmware doesn’t natively support DGUS, and so needs a pile of extra libraries to work with the touchscreen, and which translate the button presses/registers to commands to the firmware.

I’ve read of folks sinking vanilla Marlin menus onto this LCD and making them work by adding the DGUS libraries. That’s actually how I found you. I am confused however; if the LCD ultimately connects to the mainboard via a perfectly standard serial interface to a board that is really just running a version of Marlin, and if it will accept (modified or otherwise for DGUS) a standard Marlin menu, then does it not use the standard Marlin control methods–albeit mapped over whatever serial comm protocol DGUS is using?

I mean, of course it doesn’t have to. They can do whatever they want. Besides being short on RAM the LCD is it’s own animal and can pretty much do whatever you program it to. But it seems insane (and in 2021 that’s saying something) to design a whole custom IO protocol when you can just use what’s already there and working…

Anyway, thanks for the info!

Marlin 2.x does support DGUS displays. But as I said earlier “There is also some code inside Marlin itself (not based on my code, but based on my documents). But unfortunately, it is really not easy to use and understand.”

Not sure to understand. There is no extra libraries. Are you talking about the code in Marlin?

Would be better to post some links.

Again, not sure of what you are talking about. There is no “DGUS libraries”.


I am lost here.

Who is “they”?

The DGUS LCD panel is not programmed. It is configured. I often see a misunderstanding. Several people are thinking that LCD panels are DGUS ones. There are Mini DGUS, a very simplified (cost effective) version with a different MCU and several restrictions.

What is “what’s there and working”? Again, I don’t know what you are referring to. DGUS is there since a long time and has roots in Modbus.