Various LCD / backlight adjustments

[classicrocker883]

Description

• the range did not allocate difference between Max and Min (+/-) and used just one value for both +/-
  also added + to make difference of +/-

• LCD_BACKLIGHT_TIMEOUT_MINS
  added support for DWIN type displays for LCD timeout (in mins).
  LCD display and timeout and turn off after a certain amount of time has passed - screen saver-esque.

• in meshviewer, when it draws circles to indicate high or low spots on the bed, the circle colors have a more linear gradient - which is more true to how it should look, corresponding to values. also values aren't limited to 0.20. (fixed that).

• in the more recent commit for ProUI, ADVANCE_PAUSE_FEATURE "#if" statements were rearrange / ommited so that the adv pause feature can be disabled yet still utilize the other menu pages / functions.

• Updated CMakeLists.txt to stow warning for depreciated versions. Also added a "In case of..." / To Do If... comment.
  in WindowsPaths.cmake or UnixPaths.cmake in the CMake install directory, an error may appear saying unknown command _cmake_record_install_prefix(). I give a fix which simply has the user either comment out (#) that line, or add include(CMakeSystemSpecificInformation) above it which links to the file in which that function is defined.

• Renamed PlotClass. Updated to fix spelling typo (grph => graph). Changed how graph is updated, in the graph each "block" amounts to (60/2) - 30 seconds of time rather than (50/2) - 25 seconds.

• Updated proui/dwin.cpp Variable update interval, from 1024 to 1000 (ms) and 500 (ms). which updates the menu a bit faster, temp - fan speed - blink - plot graph...

Requirements

Benefits

-stated in description-
for context, this is what the fix looks like

as you can see, the high and low values are correct. -0.24.....0.22+ otherwise originally it would read -0.24.....0.24+

This also adds the ability to set a timeout for the LCD (PROUI), could be implemented in JyersUI and Creality_LCD.

---

***For SanityCheck, it was edited to quiet errors, not sure if these changes are the best but it should be reviewed.

---

The fix to dwinui.cpp for RainbowInt -- better readability/implement code, draws the color gradient with wider spectrum (more true to color >> value)* .

The fix to meshviewer.cpp allows it to draw the actual true value, instead it was limited to |0.20| on the View Mesh.

also fixed latest ProUI commit, rearrange ADVANCE_PAUSE_FEATURE functions so when it is disabled other functions like parkHead can be accessed.

---

most recent plot.cpp plot.h fixes typo, 30sec graph plot between white bars instead of 25sec.
remove redundant DWIN_UPDATE_INTERVAL / DWIN_VAR_UPDATE_INTERVAL, seperate the defined values to make better use. split
DWIN_VAR_UPDATE_INTERVAL to update display variables in half time (faster).

Configurations

#define LCD_BACKLIGHT_TIMEOUT_MINS can be uncommented - value of 10 for 10 minutes.

Related Issues

possible SanityCheck error compatibility with other configurations.

[thinkyhead]

would msg.setf_P(PSTR("%02f"), z) work?

Keep in mind that we cannot use %f with these platforms. To print floats we must use dtostrf, which is handled by the MString class using float — or one of the wrappers, p_float_t or w_float_t to set a specific precision.

[classicrocker883]

would msg.setf_P(PSTR("%02f"), z) work?

Keep in mind that we cannot use %f with these platforms. To print floats we must use dtostrf, which is handled by the MString class using float — or one of the wrappers, p_float_t or w_float_t to set a specific precision.

[classicrocker883]

everything you changed is looking good. however a couple things needed to addressed, I did the necessary tweaks. had to omit and revert back the range for JyersUI/dwin.cpp line ~400. if say you went ahead and used rmin with rmax to define the color output for values, you don't get the expected gradient.

in this part of the function void drawBedMesh

      // Draw value square grid
      GRID_LOOP(x, y) {

I know this because I tested it that way, having rmin and rmax (as range and range2) it just doesn't work well. like the highest value should be the brightest color, however this way makes it not so, and another value below that will be brighter - so it gets very confusing.

[thinkyhead]

I went ahead and cleaned up the gcode_preview.* code to address some things.

• Move Preview_ functions into a static singleton class.
• Define fileprop_t methods inside the struct.
• Apply PSTR in case this code is ever deployed on AVR.
• Return bool types in bool methods.
• Use p_float_t instead of dtostrf for some strings.
• Move thumbdata from the heap to the stack (assuming the stack can be very large).

[classicrocker883]

I went ahead and cleaned up the gcode_preview.* code to address some things.

thanks for taking the time and doing that, its looking good, ill give it a test shot. quick question regarding the G-code preview feature, when selecting to view a file with a thumbnail more than once, following these steps:

1. Go to Print menu
2. Select any file w/thumbnail preview
3. Cancel/return to file menu
4. Repeat Step 2 and 3

depending on the file, you can do this twice or sometimes 3 or 4 times until it freezes/crashes and reboots.
however if you say go to another folder or select another file w/out a thumbnail preview, this sort of clears the cache and you can do this as many times as you like.

so obviously somewhere in memory where the image is stored it overloads, there should be a way to clear the cache or address when selecting Cancel instead of print. I've tried a few different things that haven't worked like delete[] fileprop.thumbnail

more about it here. #26169

while we are on the subject is there anything which may alleviate the situation?

[classicrocker883]

just wanted to comment saying I updated the plot.cpp plot.h and made DWIN_VAR_UPDATE_INTERVAL useful in proui/dwin.cpp

[thinkyhead]

while we are on the subject is there anything which may alleviate the situation?

I found one possible culprit. The buf64[] array allocates fileprop.thumbsize bytes, then loops until nread == fileprop.thumbsize, and then buf64[nread] = '\0'. That last step exceeds the buffer size. So I just patched that.

If this doesn't fix the problem then we should look further.

[mriscoc]

Good PR! @classicrocker883 thanks for your contributions, feel free to port the features that you consider helpful from my fork to Marlin, I think that this will help me henceforth to fully focus in my fork.