Can someone explain the JohnCarlson21 LCD firmware?

Hi:

I’m in the process of deciding whether to order an SV04. I’ve done extensive customization to my current printer, which uses “standard” Marlin TFT_COLOR_UI. I’m not familiar with how the SV04 handles the display, since it appears that there is no display at all selected in configuration.h (of the Sovol 2.0.9.x source code, that is)

Can someone explain how this custom display firmware works, where it came from, what is it based on? Does it work/look like the Sovol display firmware, or is it completely different?

Any background would be helpful. Thanks!

same questions about GitHub - bphillips09/SV04-Touchscreen: SV04 Touchscreen Source :wink:

Hi,
the SV04 uses a DWIN T5L TFT LCD display, type DMG48270C043_03WTRZ35.
Display handling in the Sovol SV04 stock firmware which is based on Marlin v.2.0.9.2 is done with a custom class named LCD_RTS.h that drives the T5L display software in the DWIN display. The display software raw data can be retrieved from the Sovol SV04 stock display software using DWIN’s DGUS tool, the process is demonstrated in this YT video:
https://www.youtube.com/watch?v=smAnnwhfOvA
Brandon Phillips seems to have done this & implemented some updates + addons for the display software and in the SV04 stock firmware and posted the results on his GitHub account. He explained the changes in his current releases on GitHub. Except from altered & new functions the icons & handling in Brandon Phillips’s display software is the same.

According to the GitHub fork history John Carlson seems to have built his updates based on Brandon Phillips’ sources. The icons in John Carlson’s display software are different & far more colourful compared to stock display software, but besides from additional functions handling is the same. He explained the changes in his current releases on GitHub, too. Additionally, he posted a SV04 firmware version that is based on Marlin v.2.1.2.x

That is very helpful @Bjoern !

I’m still not clear on the concept of the DWIN display as opposed to Marlin TFT_COLOR_UI, for example. if I enable #define MESH_EDIT_MENU or #define MESH_EDIT_MENU in Marlin config, will the display just ignore it, because the structure is in the display unit? or does the actual menu structure still come from the mainboard firmware?

I never used TFT_COLOR_UI hence no conceptual comparison from me. The concept of DWIN DGUS TL5 displays basically consists of a serial data protocol & predefined sets of output screens & output elements like icons, textfields etc. & touch input elements like buttons, sliders etc. Detailled information is available for download here.
In general every SV04 firmware function with user output or input uses predefined screens with output fields / input buttons in the display software AND matching procedure calls of the LCD_RTS class. Therefore uncommenting the MESH_EDIT_MENU switch in the configuration.h file won’t help at all: Bilinear levelling is the only leveling method that has been implemented in the SV04 firmware with LCD_RTS support, UBL or MBL are not supported at all. It would need additional display screens in the display software, additional LCD_RTS procedure calls in the affected Marlin firmware classes & additional functionality in the LCD_RTS class.

@Bjoern - thanks.

Marlin with the text or TFT_COLOR_UI is very flexible, and adds menus as features are enabled/disabled. The display is more of a “dumb terminal”

I wonder if anyone has ever replaced the DWIN type display with a more marlin-integrated display from makerbase, etc? I have extensively leveraged those other marlin features like UBL in my current printer, and it would have been soooo much harder to modify two systems (mainboard, dwin) instead of one.

It would require a an other type of display with a serial bus.
I tried to find a way to exchange the DWIN display with a standard 12864 LCD display from my old SV01 printer, but it would need eight I/O pins to connect it via EXP3 port to the Creality v5.2.1 board. That would either require all optional I/O pins including my custom auto power-off function or it would require soldering on the motherboard in order to wire unused MCU pins (and the thrill not to ruin MCU or motherboard…). Therefore I kept the DWIN display with all its inconvenience.