[BUG] Bed leveling fade effectively disabled, the default 10mm is overwritten with 0mm

[CarlosGS]

The default fade height is defined as 10mm, which is a reasonable value.
But it is initialized as 0mm.

So starting with an empty EEPROM, the fading is initially disabled. I don't think it's the desired behavior since it continuously updates Z during the whole print.

Possibly related: #12410

(Tried to keep the bug report concise, thanks so much for this software, you are awesome!!)

[CarlosGS]

This is still an issue in the latest version.

[boelle]

Configurations, please
Please ZIP up your Configuration.h and Configuration_adv.h files (as
requested in the Issue template) and drop them into your next reply.
We'll check them over and see if anything is amiss.

[CarlosGS]

Hi, apart from ENABLE_LEVELING_FADE_HEIGHT, this bug is 100% configuration agnostic.

My bug report links to the problematic code lines (I've verified the two conflicting definitions are still present in the latest version).

The only thing left is to decide whether to keep 10mm or 0mm as the default. I'd suggest 10mm since 0mm keeps it enabled for the whole prints. Cheers! :)

[boelle]

so its more a config issue than a bug?

[CarlosGS]

I'd consider it an "initialization consistency" bug, since when configuring a new machine you can't enable level fade and expect an initialization of 10mm. At this moment there are two choices for users:

• On every fresh install (or eeprom clearance), manually setting a level height value, through the LCD or gcode commands, to overwrite the wrong 0.0mm.
• Manually modify configuration_store.cpp to guarantee a default initialization >0.0mm in any firmware updates.

Otherwise, some users get 10mm default fading, and some 0mm -> whole print fading (!!). Sorry if I couldn't summarize it properly before: Changing new_z_fade_height 0.0 to 10.0 would solve the issue.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[CarlosGS]

Hi, as far as I can tell, the bug is still present:

• Fade defined as 10.0 in the configuration:

  Marlin/Marlin/src/module/settings.cpp

  Line 669 in 9ade72a

  const float zfh = TERN(ENABLE_LEVELING_FADE_HEIGHT, planner.z_fade_height, 10.0f);

• Initialized as 0.0 when configuration is not available (i.e. first run):

  Marlin/Marlin/src/module/settings.cpp

  Line 2550 in 9ade72a

  TERN_(ENABLE_LEVELING_FADE_HEIGHT, new_z_fade_height = 0.0);

  
  Cheers!

To summarize: The only thing left is to decide whether to keep 10mm or 0mm as the default. I'd suggest 10mm since 0mm keeps it enabled for the whole prints.

[qwewer0]

Maybe a setting in Configuration.h would be useful?

#define ENABLE_LEVELING_FADE_HEIGHT
#if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
  #define LEVELING_FADE_HEIGHT 10
#endif

[qwewer0]

After an M502 my fade height too changes to 0.

[qwewer0]

Is there a way to get an editable fade height in Configuration.h or Configuration_adv.h? So that value is kept after a default restore?

[CarlosGS]

+1 to that solution, it would be ideal.

(Latest version renamed the file, issue still present, I've updated the above references)

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[qwewer0]

Still a problem.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[CarlosGS]

This is still present in the latest code.

To summarize: The only thing left is to decide whether to keep 10mm or 0mm as the default. I'd suggest 10mm since 0mm keeps it enabled for the whole prints.

[sjasonsmith]

@CarlosGS please review the pull request references above, and provide feedback. I believe this will satisfy your request if it is accepted.

[CarlosGS]

Yep! Brilliant! Thanks!! :D

[sjasonsmith]

This was merged, so I'll close this out.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.