Update ProUI Plot graph

[classicrocker883]

Description

This is for ProUI

update proui/plot.cpp|.h
draw connecting line instead of point to look more like a line graph
use class private variables + struct

edit:

• changed some drawIcon's alignment on dash display to be inline with other ICONs
• add ability to be a different ICON when Hotend/Bed are hot|heating or cool
• added ID_PlotProcess for Hotend/Bed Temp Plot Graph - can be used outside PID Tuning
• enlarged graph
• arrange PID plot graph code to be more user friendly
• add warnings to recommend using PID/MPC_EDIT|AUTOTUNE_MENU

---

---

if anyone is curious as to why the PID tune graph is different, that is because I added a separate way to view the temps without a PID tune. I also changed the graph to be a bit bigger. these changes are not included here or in the Marlin repo, but in my fork.

also, you may notice the Icons aren't the same. that is because I "remastered" them, basically go through each .jpg and clean it up - remove the "noise" - and tweaked them. for instance, you see the bed icon had blue wavy lines, this indicates the bed is cool. when heating, that changes to red, same kind of changes to the hotend icon.

Update for new DWIN_SET

in order to use the new ICON's, a couple changes would/should be made.

before, the two icons looked exactly the same,
ICON_SetEndTemp & ICON_HotendTemp
ICON_BedTemp & ICON_SetBedTemp

now they are like the following... these are the options depending on DWIN theme, meaning one pair for each theme. based on the picture the .jpg with 0 preceding belongs to one theme, and ICONs without are of another.

now, these ICON's should be used as follows...

ICON_HotendTemp (09) == when hotend is COOL
ICON_SetEndTemp (46) == when hotend is HOT/Heating

ICON_BedTemp (10) == when bed is HOT/Heating
ICON_SetBedTemp (47) == when bed is COOL/ above 44ºC

• in hindsight, I realize that they are kind of opposite of one another, I suppose both Set__Temp can be for HOT and both __Temp can be for COOL, but it is what it is... let me know if anyone has any thoughts, of what it could be if it needs changing.

[thinkyhead]

the Icons aren't the same

If you find the new DWIN_SET files, we can also update those in the configs repo.

[classicrocker883]

If you find the new DWIN_SET files, we can also update those in the configs repo.

sure, I'll do up a PR then.

I did a quick compile and the difference between using plot. prefix (as before) and having them static and defining them within Plot:: (as now), it uses 40 more bytes now.
is there an advantage having one way or another?

[thinkyhead]

it uses 40 more bytes now

That's an artifact of the way the compiler is dealing with data members. It should be smarter, but it's naaaht. To save 48 bytes and get the compiler to do the right thing, we just wrap the data in a struct. Might be a good trick for other classes that suffer from the same minor bloat.

[thinkyhead]

We shouldn't add the DWIN_SET and other assets to this repository (which will significantly increase its size). We prefer to keep those with the MarlinFirmware/Configurations repository since only a small number of displays require them.

[classicrocker883]

We shouldn't add the DWIN_SET and other assets to this repository (which will significantly increase its size). We prefer to keep those with the MarlinFirmware/Configurations repository since only a small number of displays require them.

yes you are right. I had this exact thought, I wasn't sure how to go about it then.

[thisiskeithb]

yes you are right. I had this exact thought, I wasn't sure how to go about it then.

They'd go in the Ender-3 V2 / LCD Files folder. Images in the private folder would need to be updated as well.

[classicrocker883]

They'd go in the Ender-3 V2 / LCD Files folder. Images in the private folder would need to be updated as well.

thanks, quick question, I notice that import and bugfix branches are near copies of each other, do I need to worry about it? or say I make a PR, do I make one for each branch?

[classicrocker883]

I just realized one little issue. I have here basically two different DWIN_SET's. one for the Voxelab Aquila, one for Ender-3V2. the difference being the startup boot logo. I guess we need to make Configurations for the Aquila??

they are almost identical to Ender-3V2, but there are some differences.

[thisiskeithb]

thanks, quick question, I notice that import and bugfix branches are near copies of each other, do I need to worry about it? or say I make a PR, do I make one for each branch?

PRs should go to import-2.1.x branch. All other branches are built from that.

the difference being the startup boot logo. I guess we need to make Configurations for the Aquila??

That’d be the easiest for users so they aren’t copying / replacing a bootscreen, but thinkyhead can weigh in on that.

edit: We have a Custom Bootscreens folder, so it can just go in there.

[classicrocker883]

I have another question, so I see that the bootscreen image is placed directly in DWIN_SET folder, with a name 0_start.jpg, however the only way I know to load the bootscreen is through ICON_LOGO which is located within the .ICO file (ex. 7.ICO, or 9.ICO) which is just like all the other icons (ICON_-----)

for instance, inside proui/dwin.cpp this is how the logo first shows, and not by DWIN_SET/0_start.jpg AFAIK

void drawMainMenu() {
...
  DWINUI::drawIcon(ICON_LOGO, 71, 52);  // CREALITY logo
}

edit:
I found the answer to this, that I didn't actually realize until just now! so the ICON_LOGO I thought was the bootscreen is totally not that. the logo is what is displayed right on the main menu. the bootscreen IS 0_start.jpg. I thought they were somehow the same, or one was not used. so nevermind on that.

moreover, does anyone by chance know how to export/import .zico files? I'm able to easily make/split .ICO using DWIN_ICO.py, but it doesn't work for .zico

[EvilGremlin]

Yep, jpg/bmp files are not used, it's just editor is janky and people don't clean up and these leftover sources are handy as preview.

[ellensp]

@classicrocker883 the private directory data including .zico files is generated from the DWIN_SET data by a proprietary application. The . zico format undocumented.

It is clearly a compressed archive that contain multiple icons, but the specifics are unknown.

[ellensp]

decoding zico, this seem to be the file structure (educated guess)

Eg 3.zico

00000000  5a 49 43 4f 50 00 00 00  00 00 01 00 0a 01 ee 00  |ZICOP...........|
00000010  00 00 00 00 25 b9 00 00  01 00 01 00 ae 00 10 00  |....%...........|
00000020  25 b9 00 00 ea 05 00 00  02 00 01 00 b4 00 0c 00  |%...............|
00000030  0f bf 00 00 71 0b 00 00  03 00 01 00 64 00 0c 00  |....q.......d...|
00000040  80 ca 00 00 66 06 00 00  04 00 01 00 7e 00 0a 00  |....f.......~...|
00000050  e6 d0 00 00 33 03 00 00  78 9c ec 9d 09 5c 53 67  |....3...x....\Sg|
00000060  f6 f7 6f c0 25 75 8d da  85 ba f5 06 37 dc 71 da  |..o.%u......7.q.|
00000070  8a 56 96 04 85 88 0b 11  6b c5 85 25 09 0a 1a ab  |.V......k..%....|
00000080  20 5a c5 b0 25 41 ab 82  ad 02 76 46 59 ec 0d 60  | Z..%A....vFY..`|
00000090  ab 04 5b 15 ec 54 16 27  81 e0 14 08 6d 81 d0 29  |..[..T.'....m..)|
...
0000d460  f1 92 98 4f fa ba 1b 5e  50 13 49 f2 0b 5d ba a0  |...O...^P.I..]..|
0000d470  76                                                |v|

4 byte Header "ZICO"
4 byte LSB/MSB, offset start of compressed data, in this eg 000000050 + 8 for header and this pointer (catalog length might be better description)

!6 bytes per file entry

2 byte file number, 2 byte version?, 2 byte image width LSB/MSB, 2 byte image height LSB/MSB, 4 byte offset into compressed data LSB/MSB, 4 byte compressed data length LSB/MSB

Name   version  width   height  offet         length 
00 00   01 00   0a 01   ee 00   00 00 00 00   25 b9 00 00   
01 00   01 00   ae 00   10 00   25 b9 00 00   ea 05 00 00   (offset =  0000b925 + 00000000 = 0000b925)
02 00   01 00   b4 00   0c 00   0f bf 00 00   71 0b 00 00   (offset =  000005ea + 0000b925 = 0000bf0f)
03 00   01 00   64 00   0c 00   80 ca 00 00   66 06 00 00   (offset =  00000b71 + 0000bf0f = 0000ca80)
04 00   01 00   7e 00   0a 00   e6 d0 00 00   33 03 00 00   (offset =  00000666 + 0000ca80 = 0000d0e6)

End of compressed data should be + 0x58 + 00000333 + 0000d0e6 = 000000d471, which it is.

Now someone just needs to work out the compression method.

[classicrocker883]

Now someone just needs to work out the compression method.

this is helpful. that was my main 'concern'. while its simple to create your own ICON's, or edit them as I was able to do, seeing how other than DWIN displays, like DACAI, use the .zico format. I was hoping basically being able to do the same thing as with .ICO, using the provided .py scripts.