New version available for testing

[Desuuuu]

A brand new version is now available for testing in the dgus-display branch.

The main changes are:

• A new interface that supports custom menus.
• Serial port configuration is now done at run-time.

The micro-controller firmware needs to be recompiled and your configuration will need to be updated.

The touchscreen firmware that goes with it is available here. The touchscreen will most likely require you to update its core firmware the first time you use it.

The Configuration reference, G-Codes, Command templates and Status reference documentations have been updated to reflect the changes. Please refer to them for details.

A sample configuration file has also been added.

Please keep in mind this version has not been extensively tested.

Feel free to report any feedback/problems in this thread.

Known issues

• The estimated remaining time goes up when calculated naively from the print's progress

To do

• Add buttons on the home page
• Bring back some custom pages from the old version
  • Move
  • Filament
• Improve long messages display

[Rokin05]

Hello and already thank you very much for developing this fork in order to be able to use the screen !
it's really awesome and i use on my Longer LK4 Pro.

1) Which version of the dgus software to use if i want (try) to view / edit the source code of the screen firmware ?
I have download version 5.04 and 7.30 but I don't know which one is better.

2) Are there any plans to prosose the integration of your work on the official source code of Klipper ?
(This makes it possible to use the Klipper update function present in Fluidd which currently does not allow you to choose a repository other than the official one.)

So I just installed this new testing version but I haven't tried it in detail yet. The base seems to be working fine for me and i have a few questions/remarks/suggestions though :

3) Should the functions DGUS_PRINT_START and DGUS_PRINT_END be remplaced by osomething else or should they simply be removed ?

4) Adding support for sd card files is great but I failed to use it (I only did one try).
Is there a limitation on the file names ? length, special characters, etc ...? (I suspect that my problems just come from there).

5) As a suggestion, I like the new interface but I find that it lacks a little more interactivity of the touch screen comparator than the previous version. for example it would be great something chosen like this : https://imgur.com/a/3j8RCd5

Thank you !!

[Desuuuu]

Which version of the dgus software to use if i want (try) to view / edit the source code of the screen firmware ? I have download version 5.04 and 7.30 but I don't know which one is better.

Version 7.30 should work fine. I think the one I've been using is 7.383.

Are there any plans to prosose the integration of your work on the official source code of Klipper ?

Possibly yes, after more testing has been done at least.

Should the functions DGUS_PRINT_START and DGUS_PRINT_END be remplaced by osomething else or should they simply be removed ?

You can remove these commands (they're not used in this version).

Adding support for sd card files is great but I failed to use it (I only did one try). Is there a limitation on the file names ? length, special characters, etc ...? (I suspect that my problems just come from there).

It works for me using OctoPrint. I don't think length would cause any issue. I tried with special characters and it worked as well (they were removed either by OctoPrint or Klipper). Make sure that your files are in the right folder (the one in the virtual_sdcard section).

As a suggestion, I like the new interface but I find that it lacks a little more interactivity of the touch screen comparator than the previous version.

Thanks for the suggestion. I might make some of these areas clickable in the future.

I don't think I'll be adding buttons though. The whole space is already used (even though everything isn't visible all the time) and I'm not a fan of having different buttons in the same place.

[ZeSlammy]

Hey @Rokin05 If you could share how you managed to make it work on a LK4 Pro ?
I flashed the screen, I updated Klipper, I'm on the dgus-display211225-6 but all I got is the splash screen :(
In Console I have a "Screen is not ready" whenever I try something.
Here the log I got klippySlammy.log

[dgus_display]
type = t5uid1
uart_bus = usart2
implementation = dgus_printer_menu
volume = 20

[display_status]

Thanks in advance

[ZeSlammy]

Ok forget about my question.
I started again set my USART to 1 and presto, it works :)

[idontknowtom]

Am I doing something wrong? I use KIAUH to install klipper, moonraker, and fluidd for my 3D printer. KIUAH defines the klipper repo as the official master branch (KLIPPER_REPO=https://github.com/Klipper3d/klipper.git) and in the past I just edit the script to clone into the Desuuuu master branch (KLIPPER_REPO=https://github.com/Desuuuu/klipper.git)

For this new version I have KIUAH do the following: "git clone --single-branch --branch dgus-display $KLIPPER_REPO"

Problem is when I go to select option for the micro-controller firmware the DGUS display option is no longer an option. What have I done wrong?

[Desuuuu]

It's perfectly normal to not have this option anymore as serial port configuration is done at run-time (through the configuration file).

[idontknowtom]

Thanks that’s assuring. I updated the core firmware and flashed the screen firmware with the flash reset (coming from older Desuuuu Klipper dgus firmware). Used your example config as below:

[dgus_display]
type: t5uid1
uart_bus: usart2
implementation: dgus_printer_menu
volume: 50

Fluidd was giving me an error and not loading Klipper. Said I was missing the [t5uid1] section in config. Which tells me I installed your master branch. So I did something wrong…

[idontknowtom]

Got it working! Was installing ADXL345 for the 1st time and switching from Desuuuu klipper master branch at the same time. Lots to go wrong, so I started with a fresh install of Pi OS Lite. Thanks for your hard work!

[markcarroll]

I'm getting error: mcu 'mcu': Unknown command: uart_send when trying to start Klipper on the DGUS-display branch. It works if I comment out the dgus_display section but does not work with it there.

mcu 'mcu': Starting serial connect
webhooks client 3041148000: New connection
webhooks client 3041148000: Client info {'program': 'Moonraker', 'version': 'v0.7.1-64-gc3f1b29'}
Loaded MCU 'mcu' 95 commands (release-210618-2-g6e103c12 / gcc: (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] binutils: (2.31.1-11+rpi1+11) 2.31.1)
MCU 'mcu' config: BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_spi2b=PI2,PI3,PI1 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_i2c1a=PB8,PB9 RESERVE_PINS_USB=PA11,PA12 CLOCK_FREQ=168000000 BUS_PINS_spi3a=PC11,PC12,PC10 BUS_PINS_spi1a=PB4,PB5,PB3 STATS_SUMSQ_BASE=256 RESERVE_PINS_t5uid1=PA10,PA9 STEP_DELAY=2 ADC_MAX=4095 RESERVE_PINS_crystal=PH0,PH1 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi3=PB4,PB5,PB3 MCU=stm32f407xx
Protocol error
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 162, in _connect
    cb()
  File "/home/pi/klipper/klippy/mcu.py", line 717, in _connect
    self._send_config(None)
  File "/home/pi/klipper/klippy/mcu.py", line 646, in _send_config
    cb()
  File "/home/pi/klipper/klippy/extras/bus.py", line 265, in build_config
    "uart_send oid=%c data=%*s", cq=self.cmd_queue)
  File "/home/pi/klipper/klippy/mcu.py", line 836, in lookup_command
    return CommandWrapper(self._serial, msgformat, cq)
  File "/home/pi/klipper/klippy/mcu.py", line 511, in __init__
    self._cmd = serial.get_msgparser().lookup_command(msgformat)
  File "/home/pi/klipper/klippy/msgproto.py", line 316, in lookup_command
    self._error("Unknown command: %s", msgname)
  File "/home/pi/klipper/klippy/msgproto.py", line 244, in _error
    raise error(self.warn_prefix + (msg % params))
error: mcu 'mcu': Unknown command: uart_send

config has:

[dgus_display]
type: t5uid1
uart_bus: usart1
implementation: dgus_printer_menu
volume: 50

previously when using the DGUS-reloaded fork, I had to choose USART1 for the display in the menuconfig.

Previous working menuconfig:

[*] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32F407)  --->
    Bootloader offset (32KiB bootloader)  --->
    Clock Reference (8 MHz crystal)  --->
    Communication interface (USB (on PA11/PA12))  --->
[*] Enable DGUS T5UID1 screen
        Screen Serial Port (USART1)  --->
    USB ids  --->
[ ] Specify a custom step pulse duration
()  GPIO pins to set at micro-controller startup

[markcarroll]

I did that. These are my current menuconfig setting:

[*] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32F407)  --->
    Bootloader offset (32KiB bootloader)  --->
    Clock Reference (8 MHz crystal)  --->
    Communication interface (USB (on PA11/PA12))  --->
    USB ids  --->
[ ] Specify a custom step pulse duration
()  GPIO pins to set at micro-controller startup

(Sorry for the confusion. I only showed the old settings to indicate that I was successfully using USART1 before switching to this branch)

Here are the versions Klipper is reporting: Known versions: host=v0.9.1-795-ge96cac17, mcu=release-210618-2-g6e103c12

[Desuuuu]

You are running the micro-controller firmware from the master branch, as indicated by the version report.

[markcarroll]

ok now I feel stupid but I can't see what I am doing wrong.

pi@octopi:~/klipper $ git branch
* (HEAD detached at desuuuuklipper/dgus-display)
pi@octopi:~/klipper $ make menuconfig
pi@octopi:~/klipper $ make

then I copy the firmware to the SD card from my Mac:

scp [email protected]:/home/pi/klipper/out/klipper.bin /Volumes/SD\ FAT\ 4GB/firmware.bin

Reboot the printer with the SD card in. It gets renamed from firmware.bin to FIRMWARE.CUR which indicates it was flashed.

What am I missing? (thanks for your help BTW)

[markcarroll]

IT IS WORKING!

Thanks for your help. It turns out the SD Card extender I am using must be problematic. I opened the case, removed the extender and flashed it with the SD card plugged in directly and it worked. It is looking good now. I will poke about and test it out. Thanks for your patience.

[markcarroll]

This new UI is awesome. On first pass it has everything that was missing from the previous version. Great job! Are you going to submit a PR back to Klipper main?

[HcNguyen111]

Success on my Creality CR-10S Pro V2.

I've managed to:

• install Klipper on my OctoPi using Klipper's installation instructions, swapping out the git clone command with git clone -b dgus-display https://github.com/Desuuuu/klipper (and obviously my own serial port address)
• make and flash the MCU
• flash my display using Desuuuu's DGUSPrinterMenu by following the Wiki in the Installation section of the README. (I flashed both the core + firmware at the same time by putting the 2 core .BINs in the firmware DWIN_SET folder of Release 1.0.0, on the same SD card.) I also replaced the TSUID1.CFG in the DWIN_SET folder with the flash_reset version from here as I came from Creality Stock FW/Marlin/TinyMachine's FW.)
• setup my printer.cfg using Desuuuu's base CR-10S Pro V2 .cfg. The only changes made were to the z-offset in [bltouch], and the replacement of the entire [t5uid1] section in the base .cfg with the [dgus_display] section from the sample configuration .cfg from the announcement/original post above.
• successfully connect to the printer in OctoPrint with Klipper state: Ready (and also install and use the OctoKlipper plugin).

Shameless questions:

1. do I now simply increase my print speed by increasing the print/travel speed/acceleration when slicing, or is there more to it?
2. What are the max/recommended speeds out there on other CR-10S Pro/V2 out there?

[UPDATE/BONUS 06/Nov]: here's my current and working CR-10S Pro V2 printer.cfg which has been tweaked and in use since I installed Desuuuu's fork (~2months at time of editing/adding this). I've also moved to a Mainsail install/OS and no longer use OctoPrint/Pi.

[Desuuuu]

do I now simply increase my print speed by increasing the print/travel speed/acceleration when slicing, or is there more to it?

Sure, you can try increasing your acceleration/speed. You can also play around with Klipper and its features to get the best out of your printer.

What are the max/recommended speeds out there on other CR-10S Pro/V2 out there?

I can't really help you with that. You might wanna experiment with the settings (or ask around).

[yborf]

Ender6 firmware working with Klipper/Fluidd.

I'm trying to follow these steps to try OctoKlipper, but whe I execute ./klipper/scripts/install-octopi.sh (-> Klipper's installation instructions octopi 0.18.0), I get this error

and cannot continue.

[espenjohannessen]

Just upgraded to this new version from the previous one on my CR10S Pro v2 and everything seems to be working fine, but I do have one question that's strictly not related to this version, but I was hoping would be solved and isn't. My workflow used to be that I turned on the printer, heated up the bed and nozzle, loaded filament, and then went to the computer, but since the controlls on the screen aren't available until I've restarted host/firmware from OctoPrint I have to get to OctoPrint first. Is there any way for the printer/screen to get up and running as soon as I turn on the printer? Perhaps I should disconnect both the printer and OctoPrint and that would solve it? I could add a screen to the OctoPrint PI by the printer, but doing that kinda makes the whole build-in screen pointless?

[espenjohannessen]

Don't know why I haven't tried before, but I guess writing the comment made me think of the obvious solution; simply powering both the printer and the OctoPi on and off together works like a charm. As soon as the PI is up and running it connects to the printer and the screen comes to life. Thanks again for the work you do and keep up the great work!

[Desuuuu]

Glad you were able to figure it out.

It is indeed not possible to use the screen without the host running, since the logic runs on the host.

[davidgalvezcs]

Success on my Creality Ender 5 Plus without problems.

In the absence of trying more, as a suggestion, is it possible to directly access the actions to increase the temperature of the extruder, bed, fan, etc ... from the icons on the main screen while it is printing?

Thanks a lot.

[Desuuuu]

It's been suggested a few times!

I'll most likely implement it, but I don't have much time to invest into this at the moment.

[simonepsp]

Tested and perfectly working on my Ender 6. Thanks Desuuu for the outstanding job. Looking forward to future developments.

Should that be helpful to anybody, here's the Klipper firmware configuration for my specific case:

.

You'll also want to change the uart_bus to usart3 to ensure a proper connection to the display [printer.conf]

[dgus_display]
type: t5uid1
uart_bus: usart3
implementation: dgus_printer_menu
volume: 20

Cheers,
Simon

[Abrooksdavis]

Thanks loads for your help. Ive got the bin file, but as I've previously experienced im having difficulties flashing this to the ender 6 main board: Im aware than the name requires changing from the last file name flash, however, ive taken the ~22/23kb, added it to an 8gb card formatted in fat32 but just cannot get it to flash.

Am I missing something obvious as I can flash the stock firmware, and have on occasion managed to get additional fiormware flashed but there appears to not be much consistency to it.

regards

[simonepsp]

Maybe you could you try with another SD card? I flashed my Ender 6 using the provided SD card (the 8GB one from Netac)

Yes, you are right. The file has to be named differently. I would also try to format the card on a Windows PC, in case you didn't try already.

Let us know how it goes.

[Abrooksdavis]

Okay, so looks like I managed to get the firmware flashed, and also the display firmware. However, im now stuck on this screen:

Tried using the flash restart T5UID1.CFG, updating the core firmware of the display too. I dont aappear to be having too much luck with this. Any suggestions? regards :)

[simonepsp]

Then you’re all set. That’s the new splash screen.
Just double-check the printer.conf file, it must contain the following lines so that the rpi can connect to the screen

[dgus_display]
type: t5uid1
uart_bus: usart3
implementation: dgus_printer_menu
volume: 20

[watzon]

I also just got it working on my Ender 6. Running great so far!

[derkaputte]

Hi,
should I give it a try, to get this running on my Anycubic Mega X, it has a DGUS display, and runs good with Klipper now, only issue it’s lack of LCD. ;)
Do I have to install Klipper from new, of your fork?
Best

[derkaputte]

Unfortunately it’s not a solution for me now. Maybe I have to set up Klipper with that branch new. 🤷‍♂️
The problem is, the screen only shows the “splash screen”, but there’s no change while Klipper connects or the printer starts.

[HcNguyen111]

😮 of course you have to use "that branch new"... and also update your LCD core firmware as stated in Desuuuu comment above (if you haven't already).

Do the following to grab the latest changes mentioned in Desuuuu's previous comment.

cd ~/klipper
git pull

or to remove your current Klipper clone (this does NOT remove you config files), then reclone the latest version of the required Desuuuu branch:

rm -rf ~/klipper
cd ~
git clone -b dgus-display https://github.com/Desuuuu/klipper.git

I'm not sure if you need to reflash your MCU when you change Klipper branches, but to do so, re-do the Building and flashing the micro-controller steps from the Klipper installation guide to flash your MCU. Desuuuu (the God) can provide input here if they'd like.

[derkaputte]

Thank you for your advise. But in my opinion, I did the following steps:

• clone the "new" branch
• compile/make the new firmware for MCU
• flash it to the MCU
• flash the display with the new firm
• get it running 😉

For now I leave it as it is, I´m on the way in vacation/holidays. So after 1-2 weeks I´ll test it again with a brand-new rpi-image + klipper...

BR Thomas

[mentallydetached]

I can confirm that I am also unable to get it working on the Mega X. Apparently when you wire the screen directly to the UART3 pins on the board, it somewhat works (screens seem a little glitchy but that might be a simple fix) but when wired stock (using the hat that sits on top of the 12864 connector connected to UART2), the screen never gets past the splash page and the klipper logs show a timeout even though I was able to confirm that the setup logic to find the main menu and initialize commands are all working successfully.

[derkaputte]

here a short update from my side. I´ve changed the RXTX pins on the display from RXTX4 to RXTX2. The connection to the motherboard is stock and thanks to @mentallydetached we figured out it is USART3.
Then the actual build pass the splash screen. But now the screen doesn´t display it very clean. The icons flickers and it show some wired numbers, incomplete/missing text.
Maybe this is an issue with the change in the resulution, because the display of the Anycubic Mega X has 480x320px.

FYI: Video shows an old connection config directly to the 2nd USART3-Header on the board.
https://user-images.githubusercontent.com/22749670/142420372-3a9402bd-4783-4f90-aa0e-341f4a1bc53e.mov

Thank you for any advise!
BR Thomas

[hieppo]

Thought the firmware works with Klipper/Fluidd and tried your fork on the Creality CR200B. The DGUS display on this printer does not work with Desuuu DGUS. But I thought the complile firmware would still work with Fluidd. However, getting error /sys/.../thermal0... error when trying to restart Klipper.

[lightswitch2159]

I noticed that this version does not have the bootloader offset option for the STM32F429.

It does not seem to boot without it.

[Desuuuu]

This is because the branch hasn't been updated in a while. I'll try updating it when I have some time.

[lightswitch2159]

That would be amazing, thanks!

[Desuuuu]

Should be up-to-date now. I haven't tested everything just yet though.

[LMS0815]

I am trying to install your firmware to my Creality CR-X.

I cloned the branch compiled the Firmware with UARTT0 option.

The only option during runtime for the printer config is UART2
Serial: nterface usart0 reserved for serial - can't reserve for uart_bus[usart0]
Bltouch: pin PD3 is reserved for usart1
Stepper_y: pin PJ1 is reserved for usart3

[dgus_display]
type: t5uid1
uart_bus: usart2
implementation: dgus_printer_menu
volume: 30
brightness: 100

After REBOOT the Printer is connected (and playing sound) and can reviere M300 commands.
Volume and Brightness are set accordingly.

Therefor I assume the serial config is OK.

But there is no menu on the Touchscreen (with new Firmware loaded).
Only the blank home screen is avaylable:

If I switch to implementation: debug the command DGUS_SET_PAGE PAGE=3 is working as well.
I assumed, that only the text can not be seen,
But if I touch the screen nothing is happening.

Please help debugging & solving the issue.

[LiadRB]

I have the same phenomenon, can also use debug and switch pages but it's very buggy.
Thats my klipper log - klippy (2).log
but I'm not sure that related, at least in my case, I will explain -

I'm getting "Error" on BIN files while flashing the new firmware ( you can see here ),
tried 2 SD Cards, both formatted to FAT32 with an allocation unit size of 4096 bytes, also tried 2 different sd adapters and different USB ports on my pc
Tried with the flash reset CFG file, same results.

It tells me to update the core files, which I did millions of times.
No errors whatsoever on core files update, taking those 2 bin files into "DWIN_SET" folder which located on the root
of the SD, but when turning on the printer after the flash it seems like no effect taken from updating the core files.

I have Ender 6, with the stock screen,
would love to use that new firmware, thank you very much for all your efforts, you're doing an amazing job!

[Desuuuu]

@LiadRB You're not flashing the right files. Follow this guide.

[LiadRB]

You were right, it now works, I guess it is the same for the other guy
Appreciate your fast and useful response, Thanks!

[Desuuuu]

Hopefully it is the same problem!

It was pretty easy to figure out since you provided a great amount of details.

[LMS0815]

My issues are gone too.

How I solved it:

1. I installed the latest version of dgus-display branch.
2. I updated the Core Firmware with the latest version available (T5UID1.CFG reset version)
3. I updated the Firmware with the latest DGUSPrinterMenu (T5UID1.CFG reset version)

Reason for the Issue

• Missing *.bin files in the DGUSPrinterMenu-master version I downloaded recently,

[VIXIVIXIV]

Hey man, long time, no see. Probably should've posted this feedback earlier, it's not about code functionality but about UI design choices. While I certainly welcome the flexibility that the new version provides in terms of adding custom menus, I feel like that's come at the cost of making certain basic tasks more tedious to perform. Specifically, I really liked the control page for jogging the axes and having the hotend temperature control on the same screen as the filament load/extruder jog buttons. There are a lot of functions that are very closely related and should be on the same screen, rather than split into five different submenus. I think a better implementation would be using the old screens (or something similar) for a few select core functions, and allowing the addition of arbitrary custom menus for other, less commonly used functions. Do you think there's enough space in the touchscreen firmware to implement this?

[Desuuuu]

Thanks for all the feedback. I see how some additional custom screens could be useful (space shouldn't be an issue). I'll try to keep that in mind once I have time to work on this.

@HcNguyen111 Are you talking about the DGUS software tools? Or the "design" for the pages?

[HcNguyen111]

I thought back on my request and it doesn't feel right. I was talking about the design of the pages... but please forget I asked. (All I was planning to do was try add touch zones to the main menu which go directly to temp/speed controls and add numerical layer progress)

I'm very happy with what I'm running at the moment and it's at where it is because of your work, thanks heaps again. (No rush on my end, do what you have to do.)

[Desuuuu]

You should already be able to do that. You can open the HMI file from the touchscreen repository with DGUS Tools to make modifications (you can find it here).

The pages are just BMP files (with an extremely simple design for the new version), you can edit these too if you'd like.

Honestly, it's not too complicated making modifications. Working with DGUS' software is painful though.

[VIXIVIXIV]

@Desuuuu I've gone ahead and loaded the old UI firmware on my printer, going to use it over the next few days to get a feel for the features that I think should be implemented in the new version, e.g. just remembered that I used the bed leveling assist feature a lot, would be nice to have that back. I'll keep you posted on the stuff I seem to use most often

[HcNguyen111]

I spy commits. I had a go at modifying the DGUS Tool project and was successful making minor size/position changes. I failed at adding touch zones though, but kind of see where I went wrong after eyeing your latest commits. Thanks for making time for it - no rush.

[thghca]

I suggest to add custom icon grid menus with same configuration logic as current lists.

[hieppo]

Any help would be appreciated but my CR-200B DWIN screen has the same resolution as the CR10s Pro / Ender6 but it seems this may be DGUS2. Not sure if that is a big difference but when I tried to flash Desuuuu klipper DWIN firmware, the flash summary only shows 3 BIN, 1 HZK and 1 LIB files were flashed. The CFG file was not flashed. The result when klipper loads, the original main screen loads and button mapping is not correct.
I do notice the original DWIN has a T5LCFG.CFG file and not the T5UID1.CFG file that is found in CR10s. Are these two firmware that much different? I notice the bmp names are the same in both the CR-200B and the CR10s Pro. Would renaming the CFG push the firmware to flash?

[RastaKillah]

Probably you figured it out, but I think I had that same error, when did not had the SD card in the right size and allocation size. Like you can not be sure that a "default option" is 4096, and you need to make a new, smaller partition from a big flash drives, if that's bigger than the supported capacity. With the old-school partition manager, you have plenty allocation options, as well you can just make a smaller partition, faking it's maximum data capacity, to cheat on these system that not supports bigger flash drives. And if you finished, you can just delete that and make a new partition from the whole drive again.
Check before flashing, not to have any extra plugged in, repeat the two flash procedure after each, maybe. On USB connections, where you only need data to go through, you should consider cutting or insulating that pin, cause they may supply each other, when you turning one off. Tricky to catch as well, cause usually mainboard supplies mainboard, and monitors or even it's main power switch can be turned off.
Don't forget to change the .bin-s name, if you do that. Try replacing the CFG file with original CFG, if not, change back.
I'm quite sure, that if you're flashing repeatedly, sometimes 15 seconds is far not enough, I think I seen the printer thinking 45 seconds, to finish the procedure, so sometimes flashing could need more time, that 1 or maximum 2 minutes is dead sure.
Also I did not known for like a day, that klipper (in case of using external controller, like a Pi) needs to connect in order to load the menus onto screen, what probably won't happen if klipper runs already, need to restart mine - if runs already - in order to realize that the printer is ready.

[NiceManiac]

Hello my friend, how is development on this going? saw there were new fixes on the klipper side of this not too long ago, but i need to ask, WHY did you remove the z-height adjustment page? and why cant the heater icons on the front page be buttons to the temperature page? and why did you remove the fantastic bed mesh leveling page from the old version?
i feel like this version is a good step in the right direction in terms of performance but the useability of it has really not been great compared to the old version. can we please have the features that were present in the old version back? the new version is great but its missing so many features.
this new version was the only one that i could get to work with my MKS monster8 board as the pin layout were incompatible with the old version, but so many useful features is missing it makes it harder to work with the printer.

[OMGrant]

I'm a big fan of what Desuuuu has done here and am currently rocking this firmware due to it's expandability. The framework for how this fork works is completely different to the other, which is why it's missing those features. I suggest changing your tact and expectations a bit, because your comment comes off really aggressive on things you think were implicit decisions made to remove things when that's far from the truth. It's a WIP homie.

[gbkwiatt]

What am I missing ? non of the firmware files have either screens.icl or icons ? *.ico are not valid to be flashed
I can generate screens with DGUS icl generator, but it does not recognize ico files. or sounds.
It all has to be in ICL format in latest DGUS firmware. I will have a go and try to convert it

[gbkwiatt]

I know I have to convert ICO to ICL but DGUS v7642 just won't accept either icons bmp files or ICO files.
Not sure what I am doing wrong.

[gbkwiatt]

Follow-up - icon files were in 32bit that's why it was giving that error above. Converting it to 24bit allows me to create ICL files.
So I have firmware uploaded and seems to be okay.

However now, I get version mismatch, and if I comment out code for checking versions, I seem to get icons but not text, it's all default values. I can navigate to menu where I only get first letters of each menu button. I've managed to home it - so communication is there.

I've regenerated all files from dgus firmware repo made for this klipper. But same result.
I am bit lost now.

I have previous attempt on static firmware working just fine, but can't make this one work.

After some more play - it looks like actually gets values but only shows first characters everywhere 🤔

[drandarov-io]

I just noticed that you created a new release for the dgus_reloaded branch. Is the work on dgus_display still up to date or should I use dgus_reloaded for now?

[Desuuuu]

That was just to fix an issue with Python 3 in the older version, nothing else changed.

[fryc88]

Have you got any plans to work on dgus-display branch?

[TechSavage1989]

I had the DGUS-Reloaded Branch running fine with Octoprint for long time but I had to reimage the Pi because of a corrupted SD, and when I try to Install klipper from the brach now I get the following error:

"  error: command '/usr/bin/arm-linux-gnueabihf-gcc' failed with exit code 1
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for greenlet
Running setup.py clean for greenlet
Failed to build greenlet
ERROR: Could not build wheels for greenlet, which is required to install pyproject.toml-based projects"

I tried to install it via KIAUH by setting the DGUS-Reloaded brach as a custom repo and got the same error. The full error is below:

" Building wheel for greenlet (setup.py) ... error
error: subprocess-exited-with-error

× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [273 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-armv7l-cpython-311
creating build/lib.linux-armv7l-cpython-311/greenlet
copying src/greenlet/init.py -> build/lib.linux-armv7l-cpython-311/greenlet
creating build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_leaks.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_generator_nested.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_stack_saved.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_throw.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_version.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/init.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_contextvars.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_generator.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_tracing.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_extension_interface.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_gc.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_greenlet.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_cpp.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
copying src/greenlet/tests/test_weakref.py -> build/lib.linux-armv7l-cpython-311/greenlet/tests
running egg_info
writing src/greenlet.egg-info/PKG-INFO
writing dependency_links to src/greenlet.egg-info/dependency_links.txt
writing requirements to src/greenlet.egg-info/requires.txt
writing top-level names to src/greenlet.egg-info/top_level.txt
reading manifest file 'src/greenlet.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'docs/_build'
warning: no files found matching '.py' under directory 'appveyor'
warning: no previously-included files matching '.pyc' found anywhere in distribution
warning: no previously-included files matching '.pyd' found anywhere in distribution
warning: no previously-included files matching '.so' found anywhere in distribution
warning: no previously-included files matching '.coverage' found anywhere in distribution
adding license file 'LICENSE'
adding license file 'LICENSE.PSF'
adding license file 'AUTHORS'
writing manifest file 'src/greenlet.egg-info/SOURCES.txt'
/home/pi/klippy-env/lib/python3.11/site-packages/setuptools/command/build_py.py:202: SetuptoolsDeprecationWarning: Installing 'greenlet.platform' as data is deprecated, please list it in packages.
!!

      ############################
      # Package would be ignored #
      ############################
      Python recognizes 'greenlet.platform' as an importable package,
      but it is not listed in the `packages` configuration of setuptools.

      'greenlet.platform' has been automatically added to the distribution only
      because it may contain data files, but this behavior is likely to change
      in future versions of setuptools (and therefore is considered deprecated).

      Please make sure that 'greenlet.platform' is included as a package by using
      the `packages` configuration field or the proper discovery methods
      (for example by using `find_namespace_packages(...)`/`find_namespace:`
      instead of `find_packages(...)`/`find:`).

      You can read more about "package discovery" and "data files" on setuptools
      documentation page.


  !!

    check.warn(importable)
  copying src/greenlet/greenlet.c -> build/lib.linux-armv7l-cpython-311/greenlet
  copying src/greenlet/greenlet.h -> build/lib.linux-armv7l-cpython-311/greenlet
  copying src/greenlet/slp_platformselect.h -> build/lib.linux-armv7l-cpython-311/greenlet
  creating build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/setup_switch_x64_masm.cmd -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_aarch64_gcc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_alpha_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_amd64_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_arm32_gcc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_arm32_ios.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_csky_gcc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_m68k_gcc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_mips_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc64_aix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc64_linux.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc_aix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc_linux.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc_macosx.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_ppc_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_riscv_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_s390_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_sparc_sun_gcc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x32_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x64_masm.asm -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x64_masm.obj -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x64_msvc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x86_msvc.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/platform/switch_x86_unix.h -> build/lib.linux-armv7l-cpython-311/greenlet/platform
  copying src/greenlet/tests/_test_extension.c -> build/lib.linux-armv7l-cpython-311/greenlet/tests
  copying src/greenlet/tests/_test_extension_cpp.cpp -> build/lib.linux-armv7l-cpython-311/greenlet/tests
  running build_ext
  building 'greenlet._greenlet' extension
  creating build/temp.linux-armv7l-cpython-311
  creating build/temp.linux-armv7l-cpython-311/src
  creating build/temp.linux-armv7l-cpython-311/src/greenlet
  arm-linux-gnueabihf-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -I/home/pi/klippy-env/include -I/usr/include/python3.11 -c src/greenlet/greenlet.c -o build/temp.linux-armv7l-cpython-311/src/greenlet/greenlet.o
  In file included from src/greenlet/greenlet.c:11:
  src/greenlet/greenlet.h:42:5: error: unknown type name ‘CFrame’
     42 |     CFrame* cframe;
        |     ^~~~~~
  src/greenlet/greenlet.c: In function ‘green_clear_exc’:
  src/greenlet/greenlet.c:173:17: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
    173 |     g->exc_state.exc_type = NULL;
        |                 ^
  src/greenlet/greenlet.c:175:17: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
    175 |     g->exc_state.exc_traceback = NULL;
        |                 ^
  src/greenlet/greenlet.c: In function ‘g_switchstack’:
  src/greenlet/greenlet.c:528:44: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘recursion_depth’; did you mean ‘recursion_limit’?
    528 |         current->recursion_depth = tstate->recursion_depth;
        |                                            ^~~~~~~~~~~~~~~
        |                                            recursion_limit
  src/greenlet/greenlet.c:529:38: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘frame’; did you mean ‘cframe’?
    529 |         current->top_frame = tstate->frame;
        |                                      ^~~~~
        |                                      cframe
  src/greenlet/greenlet.c:552:25: warning: assignment to ‘int *’ from incompatible pointer type ‘_PyCFrame *’ [-Wincompatible-pointer-types]
    552 |         current->cframe = tstate->cframe;
        |                         ^
  src/greenlet/greenlet.c:577:17: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘recursion_depth’; did you mean ‘recursion_limit’?
    577 |         tstate->recursion_depth = target->recursion_depth;
        |                 ^~~~~~~~~~~~~~~
        |                 recursion_limit
  src/greenlet/greenlet.c:578:17: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘frame’; did you mean ‘cframe’?
    578 |         tstate->frame = target->top_frame;
        |                 ^~~~~
        |                 cframe
  src/greenlet/greenlet.c:601:24: warning: assignment to ‘_PyCFrame *’ from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
    601 |         tstate->cframe = target->cframe;
        |                        ^
  src/greenlet/greenlet.c: In function ‘g_initialstub’:
  src/greenlet/greenlet.c:813:5: error: unknown type name ‘CFrame’
    813 |     CFrame trace_info;
        |     ^~~~~~
  src/greenlet/greenlet.c:857:18: error: incompatible types when assigning to type ‘int’ from type ‘_PyCFrame’
    857 |     trace_info = *PyThreadState_GET()->cframe;
        |                  ^
  src/greenlet/greenlet.c:864:17: error: request for member ‘previous’ in something not a structure or union
    864 |     self->cframe->previous = &PyThreadState_GET()->root_cframe;
        |                 ^~
  src/greenlet/greenlet.c:878:50: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘recursion_depth’; did you mean ‘recursion_limit’?
    878 |     self->recursion_depth = PyThreadState_GET()->recursion_depth;
        |                                                  ^~~~~~~~~~~~~~~
        |                                                  recursion_limit
  src/greenlet/greenlet.c: In function ‘green_new’:
  src/greenlet/greenlet.c:1018:34: warning: assignment to ‘int *’ from incompatible pointer type ‘_PyCFrame *’ [-Wincompatible-pointer-types]
   1018 |         ((PyGreenlet*)o)->cframe = &PyThreadState_GET()->root_cframe;
        |                                  ^
  In file included from /usr/include/python3.11/Python.h:45,
                   from src/greenlet/greenlet.h:8:
  src/greenlet/greenlet.c: In function ‘green_traverse’:
  src/greenlet/greenlet.c:1124:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1124 |     Py_VISIT(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/objimpl.h:199:13: note: in definition of macro ‘Py_VISIT’
    199 |         if (op) {                                                       \
        |             ^~
  In file included from /usr/include/python3.11/Python.h:38:
  src/greenlet/greenlet.c:1124:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1124 |     Py_VISIT(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/objimpl.h:200:30: note: in expansion of macro ‘_PyObject_CAST’
    200 |             int vret = visit(_PyObject_CAST(op), arg);                  \
        |                              ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1124:5: note: in expansion of macro ‘Py_VISIT’
   1124 |     Py_VISIT(self->exc_state.exc_type);
        |     ^~~~~~~~
  src/greenlet/greenlet.c:1126:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1126 |     Py_VISIT(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/objimpl.h:199:13: note: in definition of macro ‘Py_VISIT’
    199 |         if (op) {                                                       \
        |             ^~
  src/greenlet/greenlet.c:1126:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1126 |     Py_VISIT(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/objimpl.h:200:30: note: in expansion of macro ‘_PyObject_CAST’
    200 |             int vret = visit(_PyObject_CAST(op), arg);                  \
        |                              ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1126:5: note: in expansion of macro ‘Py_VISIT’
   1126 |     Py_VISIT(self->exc_state.exc_traceback);
        |     ^~~~~~~~
  src/greenlet/greenlet.c: In function ‘green_clear’:
  src/greenlet/greenlet.c:1162:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1162 |     Py_CLEAR(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/object.h:581:29: note: in expansion of macro ‘_PyObject_CAST’
    581 |         PyObject *_py_tmp = _PyObject_CAST(op); \
        |                             ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1162:5: note: in expansion of macro ‘Py_CLEAR’
   1162 |     Py_CLEAR(self->exc_state.exc_type);
        |     ^~~~~~~~
  In file included from /usr/include/python3.11/Python.h:44:
  src/greenlet/greenlet.c:1162:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1162 |     Py_CLEAR(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/object.h:583:14: note: in definition of macro ‘Py_CLEAR’
    583 |             (op) = NULL;                        \
        |              ^~
  src/greenlet/greenlet.c:1164:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1164 |     Py_CLEAR(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/object.h:581:29: note: in expansion of macro ‘_PyObject_CAST’
    581 |         PyObject *_py_tmp = _PyObject_CAST(op); \
        |                             ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1164:5: note: in expansion of macro ‘Py_CLEAR’
   1164 |     Py_CLEAR(self->exc_state.exc_traceback);
        |     ^~~~~~~~
  src/greenlet/greenlet.c:1164:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1164 |     Py_CLEAR(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/object.h:583:14: note: in definition of macro ‘Py_CLEAR’
    583 |             (op) = NULL;                        \
        |              ^~
  src/greenlet/greenlet.c: In function ‘green_dealloc’:
  src/greenlet/greenlet.c:1256:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1256 |     Py_CLEAR(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/object.h:581:29: note: in expansion of macro ‘_PyObject_CAST’
    581 |         PyObject *_py_tmp = _PyObject_CAST(op); \
        |                             ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1256:5: note: in expansion of macro ‘Py_CLEAR’
   1256 |     Py_CLEAR(self->exc_state.exc_type);
        |     ^~~~~~~~
  src/greenlet/greenlet.c:1256:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_type’
   1256 |     Py_CLEAR(self->exc_state.exc_type);
        |                             ^
  /usr/include/python3.11/object.h:583:14: note: in definition of macro ‘Py_CLEAR’
    583 |             (op) = NULL;                        \
        |              ^~
  src/greenlet/greenlet.c:1258:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1258 |     Py_CLEAR(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/pyport.h:24:38: note: in definition of macro ‘_Py_CAST’
     24 | #define _Py_CAST(type, expr) ((type)(expr))
        |                                      ^~~~
  /usr/include/python3.11/object.h:581:29: note: in expansion of macro ‘_PyObject_CAST’
    581 |         PyObject *_py_tmp = _PyObject_CAST(op); \
        |                             ^~~~~~~~~~~~~~
  src/greenlet/greenlet.c:1258:5: note: in expansion of macro ‘Py_CLEAR’
   1258 |     Py_CLEAR(self->exc_state.exc_traceback);
        |     ^~~~~~~~
  src/greenlet/greenlet.c:1258:29: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
   1258 |     Py_CLEAR(self->exc_state.exc_traceback);
        |                             ^
  /usr/include/python3.11/object.h:583:14: note: in definition of macro ‘Py_CLEAR’
    583 |             (op) = NULL;                        \
        |              ^~
  src/greenlet/greenlet.c: In function ‘PyGreenlet_New’:
  src/greenlet/greenlet.c:1777:15: warning: assignment to ‘int *’ from incompatible pointer type ‘_PyCFrame *’ [-Wincompatible-pointer-types]
   1777 |     g->cframe = &PyThreadState_GET()->root_cframe;
        |               ^
  error: command '/usr/bin/arm-linux-gnueabihf-gcc' failed with exit code 1
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for greenlet
Running setup.py clean for greenlet
Failed to build greenlet
ERROR: Could not build wheels for greenlet, which is required to install pyproject.toml-based projects"

[klack]

Did you ever find a fix for this error?

[klack]

Fixed by updating
greenlet==1.1.3
in scripts/klippy-requirements.txt