[BUG] Wrong Bed leveling calculation in connection with fade height

[stef-evotech]

Did you test the latest bugfix-2.0.x code?

No, but I will test it now!

Bug Description

It seems that bed leveling calculations give wrong values if raw z-positions are negative when fade height is enabled.

Consider this function from "planner.h":

 static inline float fade_scaling_factor_for_z(const float &rz) { 
       static float z_fade_factor = 1;
        if (!z_fade_height) return 1;
        if (rz >= z_fade_height) return 0;
        if (last_fade_z != rz) {
          last_fade_z = rz;
          z_fade_factor = 1 - rz * inverse_z_fade_height;
        }
        return z_fade_factor;
      }

for negative values of rz. In my case rz is negative because the endstop is ~8-10mm over the build platform, and my build platform moves down. So in my case I had a machine with fade height set to 10mm therefore z_fade_factor evaluates to ~2 which leads to overcompensation.

From my point of view this calculation needs a rework. Even if rz is positive, because home-offset-z is not applied, therefore I think this calculation is always wrong if the endstop/raw-z is not at print height. Please check I may be wrong on this one.

Usually I don't use fade height, but I stumbled over a machine that somehow enabled it.

This may be the reason for some other issues I read, while investigating this:
#22712
#12349
#13512

I branched/forked my firmware from 2.0.4.x but i checked the current version of planner.h and the calculation is still in place.

Bug Timeline

At least 2.0.4x

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

Check bed leveling (for example with a dial gauge mounted to print head) before and after enabling fade height.

Version of Marlin Firmware

2.0.4.x

Printer model

Custom built

Electronics

RAMBO variant

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

No response

[thinkyhead]

if raw z-positions are negative

Ideally, for 3D printing you should use G92 workspace offsets so that no raw positions below zero can ever be produced. But, the proper code change to handle negative coordinates would be to have fade_scaling_factor_for_z return 1 when rz <= 0 since positions "below the bed" should follow the same contour as positions "at bed level."

  static float fade_scaling_factor_for_z(const_float_t rz) {
    static float z_fade_factor = 1;
-   if (!z_fade_height) return 1;
+   if (!z_fade_height || rz <= 0) return 1;
    if (rz >= z_fade_height) return 0;
    if (last_fade_z != rz) {
      last_fade_z = rz;
      z_fade_factor = 1 - rz * inverse_z_fade_height;
    }
    return z_fade_factor;
  }

If you need raw coordinates below zero and –for example– your Z_MIN_POS defines that negative limit, then you could modify fade_scaling_factor_for_z to subtract the Z_MIN_POS from rz before calculating the fade.

[stef-evotech]

Ideally, for 3D printing you should use G92 workspace offsets so that no raw positions below zero can ever be produced

Hm,... But G92 doesn't change raw values,... Test:

For my machine:

M114 D
G92 Z0
M114 D

reports the same raw values, that's why I mentioned that the calculation somehow should include home_offset_z from my point of view.

[stef-evotech]

Hi again,

I thought a little longer about this issue and talked with some of my co-workers. It seems that it is more or less "standard" having the z-endstop on bed/printing height, or having the nozzle touch off the bed surface via TMC-drivers etc. For this case the mentioned calculation works because raw.z is around 0 for the print height. Minor inconsistencies neglected for values around 0 of course.

For all other printers where the z-endstop is not aligned with z=0, as I see it, there is a bug hidden here. Consequence being if you have fade height enabled and your z-endstop is not at z=0 you will face inconsistencies in bed leveling, be your endstop offset in either positive or negative direction.

So if this applies, check M420 if fade height is enabled, this may be because you are using Prusaslicer and enabled "Firmware overrides". Test if disabling makes a difference, for me it did.

Regarding a software fix. I feel this call in "planner.cpp":

 void Planner::apply_leveling(xyz_pos_t &raw) {
.
.
.

      #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
        const float fade_scaling_factor = fade_scaling_factor_for_z(raw.z);
      #else
.
.
.

should be changed to:

      #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
        const float fade_scaling_factor = fade_scaling_factor_for_z(raw.asLogical().z);
      #else

But this should be tested/reviewed by someone more experienced than I am.

Cheers

[thinkyhead]

But G92 doesn't change raw values

That's correct, and that is an important fact.

raw.asLogical().z

I don't agree. It is perfectly okay for someone to set their Z workspace offset to any value, large or small, positive or negative, and that would change the result. We want the Z fade to apply based on the native / machine space regardless of the logical workspace offsets. Workspace offsets are mainly intended for XY and generally should never be applied to Z. But, when applied to Z we do not expect printing to start at some different height. If a workspace Z offset is +100 then the slicer G-code should be doing the print starting at logical position Z100.

[stef-evotech]

I don't agree. It is perfectly okay for someone to set their Z workspace offset to any value, large or small, positive or negative, and that would change the result. We want the Z fade to apply based on the native / machine space regardless of the logical workspace offsets. Workspace offsets are mainly intended for XY and generally should never be applied to Z. But, when applied to Z we do not expect printing to start at some different height. If a workspace Z offset is +100 then the slicer G-code should be doing the print starting at logical position Z100.

I mostly agree here, but "native/machine space" is probably ambigious in relation to where the z-endstop is mounted. If the endstop is mounted at bed surface raw.z = 0 = bed surface, fading should start there, everything ok. If the endstop is not mounted aligned with the bed surface, due to mechanical restriction or other reasons regarding printer construction you would probably set your first layer height with "G92 Z0" and raw.z would be something different e.g. + or -10mm, and fade height and bed leveling will fail.

So if I understood correctly you would assume that the endstop is always mounted at bed surface height for these things to work, which is a rather restricting assumption regarding printer construction.

Regarding X/Y/Z workspace offsets and that they should not be applied to z and that the slicer should correct for z-offset, I don't agree as for above mentioned case regarding endstops. Other firmware basically forces you to establish a z=0 plane with G92 Z0 and I don't see why I would offset my slicer to acount for this for fade height/bed leveling to work.

Perhaps what I meant regarding the fix:

raw.asLogical().z

I felt the more general approach - at least regarding 3D printing - would be to establish bed surface height with a touch off sensor, sensorless homing etc. set it with G92 Z0 - at bed surface - and start printing/fading there.

Cheers

[tombrazier]

I have been thinking about similar issues and pondering submitting a PR when I have had had an opportunity to think it all through more clearly. Anyway, here are some considerations:

• @thinkyhead's argument makes sense to me, I think he is saying G92 is not for telling the printer where the head is physically positioned, it is for applying a coordinate transformation that allows the G-code to work in a logical space that is different to the physical space. Fading needs to be with respect to the physical position of the head and so G92 should not affect fading.
• @stef-evotech's point makes sense to me that there is a need to be able to tell the printer that the Z endstops do not trigger at Z=0.
• In Configuration.h there is such an option. You can set MANUAL_Z_HOME_POS to the actual height above the bed where the Z endstops trigger. As a consequence Z=0 will then be at bed height. I use this myself because my printer has the exact problem @stef-evotech describes: my Z endstops trigger at about Z=0.25mm.

There are also further issues here that I am thinking about:

• If the average Z position of the bed is not zero then fade height ends up applied to that entire average position. This is undesirable and, I think, not what fade height is for. I had a case when my Z endstops used to trigger at about Z=1mm and I had not set MANUAL_Z_HOME_POS. The resulting print was 1mm thicker than it should have been because the first 10mm of height ended up stretched to 11mm. I think ideally fade height would be with respect to the average bed height rather than Z=0. This is easy enough to accomplish but would add a float to the core RAM footprint. But it would resolve this entire conversation.
• In regards to RAM footprint, I think we can improve the specific case of BILINEAR with subdivisions by maintaining just one grid rather than the probed grid plus the Catmull-Rom grid.
• I have a nagging feeling that apply_leveling() and unapply_leveling() do not use the same fade factor whereas they should. I think they both calculate fade height using Z from current_position which is different depending on whether fade is enabled or not. This is something I want to look into when I have a chance.

Anyway, for now, use MANUAL_Z_HOME_POS. It does the job very nicely.

[stef-evotech]

@tombrazier: As for me personally, the printers I'm working with have a touch-off sensor in the print bed, so I touch off my surface evertime before I print and before I do a G29. So while changing the define for each printer individually would work yes, but would be impractical and would not account for heat deformation or endstop mounting etc,...

By the way: no need to worry about me, I implemented the fix I mentioned because I felt that it is what is right for our printers. Furthermore I don't use fading, I only stumbled over this because Prusa-slicer adding a M420 Z10 to a printer, which broke bed leveling (in connection with endstops not being on Z=0).

But to sum this up, this:

 static float fade_scaling_factor_for_z(const_float_t rz) {
    static float z_fade_factor = 1;
    if (!z_fade_height || rz <= 0) return 1;
    if (rz >= z_fade_height) return 0;
    if (last_fade_z != rz) {
      last_fade_z = rz;
      z_fade_factor = 1 - rz * inverse_z_fade_height;
    }
    return z_fade_factor;
  }

may still pose a problem for fading/bed leveling if your endstop is not at bed surface, because the parameter passed to it - as for now - is raw.z. And for me personally this should be changed. I think the more flexible approach is to set print start height with G92 Z0 as Raw.z = 0 may be something completely different, depending on the construction of the printer, changes due to heat deformation, etc. But people may see this differently and thats the beauty in such things, thanks for the discussion and insights @thinkyhead @tombrazier!

Cheers

[github-actions]

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

[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.