-
-
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
[WIP] MarlinUI for Creality DWIN #19371
[WIP] MarlinUI for Creality DWIN #19371
Conversation
c619181
to
7182c78
Compare
@thinkyhead I think you missed some White -> Color_White changes in Also:
|
Can we pull from the libiconv library for text encoding? https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=blob_plain;f=lib/gb2312.h;hb=HEAD |
7182c78
to
a15cdb3
Compare
We first need to know what character encodings and font formats these HMI / DWIN screens understand and then simply do the usual translation, as we do for any screen with limited capabilities. |
Per the T5UIC1 application guide it expects GB2312.... I pulled the font file for the screen apart here |
Still getting:
Is that a definition issue or a required change missing? I should note that I'm attempting to do this with a BLTouch enabled... |
Not sure if this helps, but this is the character mapping, I can format this any way needed Also did a quick scan through the translation files and noted anything not mapped |
FYI - the Creality CR-6 SE source code is now also available if you need to take a look. Currently available on a Google drive link as it has been release through Naomi Wu, so not yet via the official website. EDIT: Source code of Creality appears to have been based on commit 25a7cea. I've "merged" their changes on top of that commit 25a7cea, so can see the changes they've made: Sebazzz@f3876e8 |
This draft is pre-alpha and it has been made public for collaboration. |
4f27b82
to
dba7167
Compare
817ba1e
to
acd3ce9
Compare
acd3ce9
to
c6f92c4
Compare
Generally, you'll just tailor the drawing to whatever DWIN / HMI system you have installed on the display. This PR is built on the assumption that the basic assets included by Creality3D will be installed on the display, but later we'll add our own custom images in the form of JPG files and draw parts of those. And, I have the original asset files from Creality, so I can edit those in the appropriate tools, which exist only for Windows, or replace their assets entirely, and generate our own ICON assets. I just want to get this into working order with the basics in place first, and then I can start doing more enhancements. Since your display doesn't have a knob, you could start out just trying to make a Status Screen that draws temperatures, fan speed, SD status, status message, etc., in the landscape layout. You'll notice that other fancy color displays which could do a Status Screen layout more suited to the extra space are —for the moment— just following the layout of the DOGM128 display. You can imitate the DOGM128 layout if you want to, but don't feel constrained. |
83cc0bc
to
73f6426
Compare
1eaff6a
to
aee971b
Compare
9852ef9
to
0e40d47
Compare
In case anyone is interested: It boots up and 'works' on my Ender 3 V2, which is a step more than I got the last time I played with it. You can cherry-pick the last Some notes:
Current state (as-is, unchanged):
PXL_20210613_185730337.mp4Note the blink on each refresh. That's about all my motivation for this Sunday afternoon, but now that's it's building and booting again I will probably poke around with it..and hopefully this will spur some others too! |
Seems very good, I will try to replicate your goals and do something also. |
A tiny bit of progress, but menus are almost usable: There's an additional commit in my branch linked above with these changes. Note: these changes are very messy but I'm putting them out here in case it may help someone else who's looking at this before I get the chance to try some more. edit: as you can probably see, the display is slow. Poking around, this appears to be because everything is sent one. character. at. a. time. I would think for this particular case, it would probably make more sense to build the strings first and then send them once...but that can be refactored later. another edit: I've added another commit that switched things from being sent 1 character at a time to sending full strings. What a difference! With that change, the menus are very functional. There's still a few things missing, like the confirmation screen and UBL screens, etc..but it is minimally useable at this point. I've also been working on arranging the status screen like the DOGM128 display, with some icons pulled in from the existing assets (yeah they are kind of tiny): This isn't in my branch yet, but I'll add another commit for it once I'm at least somewhat happy with it. |
Some more updates to my branch. Started playing around with icons and animation (also found a bug in Creality's part of the DWIN code, shocker!). This is all now in my branch, including the needed DWIN_SET (icons) and my configs I've been using for reference (theeg-configs). This is currently usable enough that I'm actually printing on it, between making changes/flashing: PXL_20210618_142311207.mp4I'm going to move forward with more changes including landscape mode and then hopefully have it cleaned up and ready to create a separate PR soonish. |
If anyone happens to come across a screen mount for the Ender 3 V2 (being the main DWIN victim at the moment) that will do landscape, I wonder if it'd be worthwhile linking it in with the code... |
It's ultimately up to Thinkyhead I imagine, but I can't see why that'd be done in general. It would be one more thing to maintain (links go bad, etc.) and there are constantly new designs popping up, etc... I imagine if enough people start using this in landscape mode multiple designs will pop up. In fact, I'm already thinking about how I'd design it...in addition to the issue of maintaining a link, I don't think we want to try to decide what design is 'best'! (and then have users submit issues because they disagree). That being said....landscape is quite nice on this. I think it's officially resurrected mine from the 'stuff I might use one day' shelf: (still needs some tweaking, but not bad imo) |
@enigmaquip , if I'm reading your comment & decode.go script correctly, it looks like the first part of the HZK font file is a set of 1-bit bitmaps, one for each size, for ascii 0-127. Bitmaps meaning the very basic sense, literally just a set of 0/1 bits, arranged so that each font bitmap is 16 characters wide, with the data padded so that the rows are aligned to byte boundaries. If that's the case, it should be pretty straightforward to convert the marlin fixed font to this HZK format, but it will have to be scaled up for the larger sizes. I did find a program from DWIN that claims to be able to generate the font file automatically, but it appears to only work on TTF fonts, and they have to be installed on the system so you can't just pick any random font file. |
This work you're doing is unbelievable! I'm really glad that this display is not dead yet. Someone above mentioned the Here is the reference for the BTT TFT support: Klipper3d/klipper#2231 |
Thanks! Based on what I've seen while working on this: no, it wouldn't be nearly that simple. The concept is similar, the DWIN lcd is running it's own firmware and just listening to Marlin via a serial connection, but the protocol is completely different. I've linked the reference docs in my PR, #22211. |
I see. Should have checked your commit. Got excited and thought this was emulating some basic LCD. 😬 Anyways, if there are people still interested into porting this to Klipper as well I'd be more than happy to help with testing or anything. There's some success with touchscreen DWIN displays (T5UID1 based) but from what I've read, that one is DGUS based and works a bit different than this T5UIC1 on the E3V2 display. |
This PR provides the beginning framework for a MarlinUI implementation supporting the DWIN screen with click-wheel control that comes stock on the Ender 3 V2. With a little more work this can be extended to handle touches on the CR-6 SE as we do with other touch displays.
This PR is currently in very rough alpha shape, and needs a lot of work. At this stage the firmware compiles and some elements of the display will update, but the drawing is not yet stable, and we still need to gather information to handle text encoding.
So, this is a starting-point to fix up the drawing code and get the full
MarlinUI
implementation fleshed out for this display in both Portrait (initially) and Landscape mode. Although this aims to initially work without the need for extra assets installed, just drawing basic boxes, for completeness the final version should have a full Status Screen that requires our own color assets to be installed on the display.