-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MarlinUI for Creality DWIN (ie. Ender 3 v2) #22211
Conversation
Annnd, it appears that this does break the stock v2 UI. I'll take a look at that too. |
Will Manual Mesh Bed Levelling also work with this PR? |
@ETE-Design I haven't verified it directly, but it should since 'anything' that would work with a standard LCD screen with the standard MarlinUI menus should work with this without additional modification. |
It's building successfully now, but I haven't had the chance to reflash the stock assets and actually boot it up yet. |
Confirmed that these changes are compatible with the Creality/Stock DWIN UI and that switching back and forth works as expected. Note: the below font file will need to be added to the stock DWIN_SET files in the example configs for those that may wish to flash back to stock after using this. |
Thanks for your efforts! With #19371 I got stuck on the correct handling of screen drawing commands and simply never got back around to solving them. Looks like I can close that, and/or cherry-pick parts of this that fill in where I fell down.
I think it's totally OK to completely replace the DWIN UI when using MarlinUI, replacing all the assets. Of course, if there's enough room for both, we can just put the MarlinUI assets in their own files. In the long run we'll most likely replace the existing DWIN/E3V2 code with the code by Jyers, at which point we'll make a super-hybrid This looks really good so far, and I look forward to going forward from here! I've got to take a pass at the PR pile and then put out a quickie minor release, but later on I will flash this on my E3V2 and start messing around. |
It was actually broken at a code level originally, I've fixed it so that it builds for either UI now. (You do have to switch assets to swap back and forth, of course). Trying to support both with a single set of assets is going to come down to the font: It doesn't appear possible to have more than 1 font installed and select it at runtime. I think the font I created looks better than the stock, and you could just use it for both...but I'm sure you could find someone who prefers the stock UI who would complain that it doesn't match. The icons are also a bit finicky. It seems possible to install multiple icon libraries and reference them, but it didn't always work. I had the best luck just overwriting the existing It's also worth mentioning: I fixed some bugs in the original DWIN UI code ( I've been using this as a reference: Note that the guide is for v23 and all of the DWIN_SET assets I've seen floating around are all v20, so not all of the functions there seem to work. Notably draw bitmap. I couldn't get that one to work even after upgrading to v23.
Thank you! |
I've added the additional bdf font files I created and a Python script that will create the HZK font based on them to Also, if you happen to take a look at the new fonts, not all of them have been smoothed and for those that have, only 1-128 have been since that's all the HZK font can hold! |
I tweaked the code to draw editable values in menu items in a different color, but now those values flicker on menu redraw. It might be due to the way these particular strings are drawn. The title is printed first, and then the value in the other color. Interestingly, the titles in white don't flicker. So, maybe there is some erase step happening before the value draw. |
Strange, I pulled the changes down, built and flashed and it seems fine for me: PXL_20210705_001310041.mp4I've gone to some lengths to keep that sort of flickering from happening, because as you allude to, doing multiple draws across the same area on the same 'pass' can cause that. I don't see anything within |
You may want to flash again, as that Fan speed "0%" should appear in yellow. I have also spaced out the menu items a bit because the skinny font can make them appear somewhat squished together. I'll also push a change shortly to move the menu item text a little bit in from the left edge. |
Nozzle, Bed and Fan Speed values are all yellow in my video, my phone just does a terrible job on auto white balance/brightness with the screen.
That makes sense! I've toyed around with bumping up the font size for the menus to compensate for the 'squished' feeling, but that didn't have the right effect either, so I just left it alone. |
When the knob is turned the yellow values flicker, so I'll still need to figure out why that is happening.
This is a good opportunity to improve some other areas and set a standard for other display UIs. For example, the edit screen is known to be relatively tall (i.e., it's definitely not a 16x2 character LCD) so it can draw everything centered across multiple lines, use the largest font for the numeric value, and show a "progress bar" at the bottom for values that have a range. I'll play around with some of that stuff today, and also try to sort out those flickering values. |
One thing I left off, but which could definitely be better applied, is the drawing / handling of menu items for a screen that has a persistent internal buffer and can scroll its contents. The code provided by Creality only does drawing of the previously-selected item and the newly-selected item when the knob is rotated, and it uses internal DWIN methods to scroll the screen quickly. The current ( |
FWIW, I've been using this on my v2 since before I created this PR, and I've been reflashing as changes are made...probably at least 40-50 printing hours done so far (mostly via OctoPrint), with no major issues. So far the only big thing is OctoPrint disconnecting when I didn't have the LCD cable plugged in snugly (loose after moving it around, so self inflicted). With that said, it seems very stable and I haven't run across anything that I felt was missing or wrong. One caveat to that is that I do not use a Z probe and I use UBL with Also, the new edit screen looks very nice with the progress bar. The bar does make the encoder feel a bit slow...trying to trigger the 'fast' speed seemed a bit unreliable, but I could have just not noticed it before. I'll poke around with those settings. And finally, if it hasn't been done by the time I have the chance to look at it: I'll see about adding an 'Info/question' icon to the assets and sprucing up the confirm/alert screen a bit, maybe more to the theme of the halt screen. |
Yes, it does highlight some areas that need improvement. Temperatures should definitely be "FAST" edit items, and the same is true for any item that has a very large range. I noticed that some items are intended only to display a message and not actually be editable, so I will have to hide the bar on those.
You can use the graphical LCD version of the code for reference. The graphics overlay shows how rotation direction will affect the value and Z motion, and it uses a couple of flags to decide which directions to show. During editing a nozzle graphic is drawn either raised up or lowered down to indicate the most recent direction moved, giving some feedback to make up for controller latency.
Also a red stop sign with a white X for the KILL screen? It would be good to standardize our alerts, warnings, and fatal errors, and especially to give good feedback for certain procedures. For example, during testing I noticed that if you start PID Tuning (from the screen or with |
Like the DOGM/LCD implementation, the nozzle and arrows move up/down a pixel based on the last movement. You'll need to update the ICON asset: Since I was making icons, I also took the opportunity to remake the existing icons as SVGs and then rasterize them into JPGs. My lack of creativity/artistic skills aside (these are basically just the DOGM icons that have been colorized), I think they look better. I also created a question and 'alert,' although they are currently not in use: And some additional icons for the babystep overlay: |
Oops, I see that one of the fan frames is chopped off at bottom. I'll check whether that's code or the ICO…. |
Ok, made some adjustments:
I made the fan icon square, because there's actually only a single svg now. It's just rasterized 4 times, with 3 of those being rotations (that are cropped to be square again). I've also updated the status screen code to account for this, but if you just flashed the new icons without flashing the new code it would be cut off on the bottom.
This would be a good point to start layering icons, I think. Actually, the nozzle and bed + on icons probably should be layered too, but it's simple enough to just have 2 separate icons...but adding in bed leveling would compound that. By layering, I mean enabling transparency so that we can 'stack' multiple icons on top of other. I was playing around early on and had this working, you just have to be careful with the JPG compression since the transparency is based on a single color. The current DWIN functions are just hard coded to not do this, but it would be fairly easy to make it an argument, I think.
I've been giving this some more thought too...encouragement to poke around at the code more! 😄 So, as an added bonus, after stumbling around some I've gotten to this: It needs more cleanup, but hopefully it will be at a point where I can push up a commit with it soon. |
Thanks, but I had already posted a more complete version earlier: #22211 (comment) |
OK, deleted |
I haven't been able to reproduce this, so maybe I was just seeing things. I did however confirm that the status message is no longer scrolling with |
I'll have a look at those. |
b6aa414
to
e77c2c5
Compare
Turns out renaming that file to |
I might have spoken too soon. I need to consider the menu item images for English and Chinese too. One way I can save space is to move the boot screen elements into an ICO file, then only a single instance of the logo and accompanying text will be needed. |
I think that is time to get rid the menu item images for English, it had some sense when the resources were abundant, but now, I think that the display flash memory space can be used better. |
ee137ab
to
bcee397
Compare
Here is the updated
Applied some fixes for CrealityUI…
More CrealityUI patches later…
|
812f110
to
3bf97a1
Compare
Is there actually a chance that umlauts can still be added? |
That's going to be a challenge with most translations for this implementation, I think. The font file on this DWIN supports only basic ASCII (0-127) and GB2312. The basic ASCII doesn't include any accented, extended or special characters normally. MarlinUI already 're-purposes' some of the normally non-printable or otherwise unused characters for things like the menu arrows and the degree symbol, but I doubt there are enough left to create a full set of characters needed for many translations. GB2312 is Chinese specific encoding, and the stock fonts are all Simplified Chinese characters appropriately. In theory you could use some of these characters to hold the extended characters needed, but they are a different shape. The ASCII characters in the font are rectangular, and have bitmaps for each size (ie. 6x12, 10x20, etc.). The GB2312 are square and are only 16x16. My other thought on this is that we could 'steal' a few more of the ascii characters to use as accents, umlauts, etc. Then an extended character could be 'composited' together, by first drawing the normal character (with appropriate background) and then drawing the 'extension' character over the top of it, without a background. This approach would have the significant drawback of a drawing performance hit. Sending individual 'text' commands with single characters is much slower than a single call with all of the text. Doing this in a manner that is still performant would be challenging. |
The HD44780 support includes translation that maps accented characters to non-accented characters, for cases where the display only has Cyrillic or Japanese but not Western Accented. So, that same basic technique would need to be used to map an ASCII-127 font on other limited displays. Adding accents using extra calls would slow things down, but there aren't too many instances where lots of accented characters are needed at once, so it's worth experimentation. I'll be curious to figure out how to use GB2312 since 16x16 could be useful to make things more readable from a distance, and character-based Chinese support would be very welcome. |
c04b2af
to
e2297d8
Compare
3bf4860
to
e2297d8
Compare
I accidentally pushed The PR is just about ready, so I may just merge it into bugfix tonight, after I've done a little more tweaking of the status screens. With this merged I will be able to focus on the enhanced and jyers updates for the stock menu system. It will be interesting to look at the GB2312 support soon and see what that entails, because it would be great to have Chinese support "for free." |
Just a reminder: the font I created doesn't include the GB2312 glyphs. It would be simple enough to just copy them from the original font if needed. |
Ah, I see… I had the impression that the display included GB2312 as part of its ROM. What is the extra cost for adding GB2312 to the |
I finally merged this in somewhat refined form, with some minor changes in layout and support for up to 2 extruders. I'm sure there are many more improvements to be made. For example, if only one or two fonts are used then the others may be removed to recover space (if that helps). Maybe the standard menu font should be a size larger, at least as an option. When a final version of the Enhanced / JyersUI extensions of the "Creality UI" is ready to deploy, at that point we could add the GB2312 translation layer as a start towards improved language support, and then look at Japanese, Cyrillic, Greek, etc. Of course, Western Accented support with ISO10646-1 would also be a welcome addition. The main advantage is that all fonts are monospaced bitmaps, so we really just need UTF-8 fonts with exact parity to the DOGLCD fonts (except of larger size) and then all the existing translation code would apply. |
@llamaonaskateboard I use these here with no problems: |
Unfortunately, that won't help, as I explained previously. According to DWIN, the font file is separate storage from the jpg/ico assets. Even if the documentation is wrong, it's basically just an array of bitmaps. You could remove the larger sizes that we don't use, I think, but all of sizes including the largest we do use would have to be included. It's a very minimal format, no indexing or headers, literally just a series of 1bit-bitmaps one after the other. The firmware assumes they are all there, from what I can tell and is probably using hard coded offsets. |
Worked it out, got bitten by SD card sector size and it wasn't actually flashing. Can a note be added to the README in the examples to say the SD card must be formatted FAT32 with a 4096 byte sector size (Windows 10 default is 8192 bytes)? |
I was just typing out this in a reply when your comment popped up. I would agree that this needs to be pointed out since the DWIN screen will still flash blue/orange very quickly when the card isn't being read properly. |
I've seen it pointed out here and there that FAT32/4K is required, but it can't hurt to add the note to all the pertinent README files in the Configurations repository. |
Description
I'm still tweaking some things and there are a few TODOs still, but this is at a point that I think it warrants some discussion, testing and a PR.
A MarlinUI implementation for the DWIN screen included with the Ender 3 v2. Based on Thinkyhead's initial work in #19371.
Includes both landscape and portrait modes, Marlin bootscreen, custom icons and fonts.
Status screen layout is based heavily on the DOGM status screen with some liberties taken for the differences in sizes/ratios.
Landscape:
Portrait:
Menus:
Halted screen:
As with #19371, this is enabled with one of two options in
Configuration.h
:#define DWIN_MARLINUI_PORTRAIT
#define DWIN_MARLINUI_LANDSCAPE
Additionally, the LCD will need to be flashed with new assets. See DWIN_SET.zip below.
The fonts are based on the marlin 'fixed' 6x12 BDF font file that I scaled up and manually smoothed out. The resulting HZK does not contain the additional 16x16 glyphs, so only ascii 0-127 is supported for this font, currently.
Tested (both landscape and portrait modes):
While I did start with Thinkyhead's commit, this has diverged quite a ways from that. Notably, I moved some of the code around into different files:
src/lcd/dwin/marlin/ui_common.cpp
- these are the MarlinUI functions that should work for any similar DWIN even at different resolutions, assuming that the proper defines are setupsrc/lcd/dwin/marlin/ui_status_480x272.cpp
- these are the MarlinUI functions (mostly the status screen) that will only work for a 480x272 DWIN screen.src/lcd/dwin/marlin/marlinui_dwin.h
- this wasultralcd_dwin.h
, but since I splitultralcd_dwin.cpp
into the above files I think this name is more appropriateI also created an additional class,
DWIN_String
. This is modeled afterTFT_String
and is used heavily throughout the code to enable sending entire strings at a time instead of single characters. Sending entire strings is absolutely necessary in order for the menus to be usable.TODO:
BABYSTEP_ZPROBE_GFX_OVERLAY
/MESH_EDIT_GFX_OVERLAY
LCD_SHOW_E_TOTAL
Requirements
A 480x272 DWIN screen with an encoder, ie. the DWIN included with the Ender 3 v2.
Updating the DWINs assets (see DWIN_SET.zip below)
Benefits
Implements the standard MarlinUI status screens and menus for this DWIN LCD. Specific features do not require updates to the DWIN assets, etc.
Configurations
Ender 3 v2 configuration
Ender3v2.zip
DWIN firmware and assets (DWIN_SET):
DWIN_SET.zip
edit:
If you come across this PR because you have an Ender 3 v2 and are interested in testing, please do!
If you aren't familiar with how to do that:
marlinui-crealitydwin
branch . Or, you check it out from your existing clone of the main marlin repo:git fetch origin pull/22211/head:marlinui-crealitydwin
git checkout marlinui-crealitydwin
#define DWIN_CREALITY_LCD
#define DWIN_MARLINUI_PORTRAIT
or#define DWIN_MARLINUI_LANDSCAPE