Status msg, DWIN temp fixes

[classicrocker883]

Description

Fixes a couple small issues in the console/terminal.
It will say Printing... after heating - (in simulator) using these commands:

M104 S55
M140 S55
M109 S55

So the fix is to add a stop timer during first boot / initialization, however it doesnt fully go away after the initial start. it will keep saying this even though it isnt printing after a few more heating commands.

Fix AUTOTEMP_FACTOR resetting value. previously, the default value has no real effect. now it stays unless changed

• Only update factor if 'F' is strictly seen. If 'F' is NOT seen, we do nothing, preserving the previous or default value (0.1, 0, etc.)
• 'F0' still disables; 'F' by itself uses default. preserves original function: enabled using 'F' or 'F#'

Fix having no PREHEAT_LABEL for M303, Creality, ProUI, JyersUI LCD

Update PID_autotune logic. safeguard zero. dynamic time delay 5000UL for bed/chamber 3000UL for hotend - because hotends heat/cool at a faster rate.

Hush warning when using certain Configs (happened when testing with simulator) in lcd/dogm/status_screen_DOGM.cpp, uses correct u_long instead

In static member function ‘static void MarlinUI::draw_status_screen()’:
Marlin/src/lcd/dogm/status_screen_DOGM.cpp:583:33: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
  583 |         sprintf_P(xstring, PSTR("%ld%cm"), uint32_t(_MAX(e_move_accumulator, 0.0f)) / escale, escale == 10 ? 'c' : 'm'); // 1234567mm

We could use PRIu32 instead, either way..

Requirements

Benefits

Configurations

Related Issues

• Not sure to remove HAS_MULTI_HOTEND line in Temperature::set_heating_message - temperature.cpp
• Not sure if having POWER_LOSS_RECOVERY check is needed or not in MarlinUI::init - lcd/marlinui.cpp

---

• AUTOTEMP_FACTOR seems to be useless. looks like M104 must use a value with F otherwise without F or a value for it it resets to 0.00
  fixed in this PR

[ellensp]

Th UI has always displayed E1, E2 etc while code says E0,E1 etc This is a deliberate design decision as UI users are not programmers (in general) and expect number to start at 1

[thinkyhead]

The design of AUTOTEMP is not great, but it is what it is and the behavior and G-code should not be modified without directly consulting the original author of the feature and users who employ this feature in their workflow.