Marlin: LCD cannot adjust negative floating point number as "%3.2f"

[mateddy]

##Hardware:
Kossel Mini, allen wrench as z-probe, Reprap discount smart controller, 1.1.0-RC7

Symptom:
EEPROM can load and store the value of zprobe_zoffset (-10.0f < x < 0.0f) via M851. The LCD can load the value correctly, but when entering in the menu to change, text became garbled.

Investigation:
As autotemp_factor is also use the format "float32", I modified line 1647 to a range of -1.0 to 1.0. The default value shown is 0.10. When I decrease the value to less than 0.0, the text become garbled. However, as I increase the value to be positive again, it is all good.

Source of problem:
Unidentified yet. However, function char* ftostr32(const float&) seems not the issue.

[thinkyhead]

See if the problem still exists in the RCBugFix branch and then report back.

[mateddy]

Still has same issue (Using commit https://github.com/MarlinFirmware/Marlin/commit/092e949b581e4f6aaf27cb89aaaa0005865ef711)

[thinkyhead]

I'm unable to find any obvious cause for this issue, and unfortunately right now I don't have access to an LCD controller to test with. Perhaps I can make a branch with extra logging in the LCD code that you can test, and maybe it will reveal something.

[boelle]

@mateddy so if you download from here: https://github.com/MarlinFirmware/Marlin/tree/RCBugFix

you have the same issue?

[thinkyhead]

you have the same issue?

He said he did:

Still has same issue (Using commit 092e949)

[esenapaj]

Perhaps M502 and M500 are needed?

[boelle]

"Still has same issue (Using commit 092e949)"

and that did not tell me if he used RC7 or RCBugfix or something else

[Blue-Marlin]

[mateddy]

@esenapaj Tried all M50[0-3] and also M851 (which set the zprobe_zoffset directly), on my own 1.0.0 build, 1.1.0-RC7 and latest commit on 32-Bit-RcBugFix 14ec291 just now, but LCD still can't handle negative floats

Side note: X and Y coordinate shows well, format is [+-][0-9]{3}

[thinkyhead]

@mateddy I've started a branch for debugging. Give this an initial try just to see that it works. I don't expect the issue to be fixed, necessarily. I just did a little cleanup on the code to make it more sensible: https://github.com/thinkyhead/Marlin/tree/rc_lcd_edit_tweaks

I will add some debug logging to this branch soon to see if we can isolate the issue.

[mateddy]

@thinkyhead Your branch fixed that. However I can't see what make your branch work and 1.1.0-RC7 doesn't...

[thinkyhead]

@mateddy Sometimes being more explicit about float versus int makes a difference. That's the most distinct change that I made.

[thinkyhead]

Here are the significant changes:

      if (lcdDrawUpdate) \
-       lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition + minEditValue)) / _scale)); \
+       lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition + minEditValue)) * (1.0 / _scale))); \
      if (lcd_clicked) { \
-       *((_type*)editValue) = ((_type)((int32_t)encoderPosition + minEditValue)) / _scale; \
+       *((_type*)editValue) = ((_type)((int32_t)encoderPosition + minEditValue)) * (1.0 / _scale); \

…and…

- menu_edit_type(float, float3, ftostr3, 1);
- menu_edit_type(float, float32, ftostr32, 100);
- menu_edit_type(float, float43, ftostr43sign, 1000);
- menu_edit_type(float, float51, ftostr51sign, 10);
- menu_edit_type(float, float52, ftostr52sign, 100);
- menu_edit_type(float, float62, ftostr62sign, 100);
+ menu_edit_type(float, float3, ftostr3, 1.0);
+ menu_edit_type(float, float32, ftostr32, 100.0);
+ menu_edit_type(float, float43, ftostr43sign, 1000.0);
+ menu_edit_type(float, float51, ftostr51sign, 10.0);
+ menu_edit_type(float, float52, ftostr52sign, 100.0);
+ menu_edit_type(float, float62, ftostr62sign, 100.0);