RC8 And latest Bugfix - Auto levelling forcing nozzle too high above the bed.

[rhinorap]

Hi,
i've come over to marlin after loosing patience with Repetier and it's apparent lack of support for new technology.

I have a Prusa here running on a Rumba board probing with a (legitimate) Bltouch.
Probe is working fine, machine homes to all axis happily, including a sexy z home that kisses my slip gauge nicely, proving the Z_Probe_offest is set correctly.

With both RC8 and the latest Bugfix, G29 plods off merrily and probes away, reporting back minor deviations - BUT during a print it's pushing the nozzle appx 1mm above the bed consistently.
I tried to trick the height but ended up eating kapton tape - I did notice however that in this instance the grid seemd inverted on the bed ?

I see many many reports of similar behavior, but currently no concrete resolution ?

[rhinorap]

Interestingly after a typo due to drinking tea and trying to multitask, I ran a g29 z4 the nozzle corrected again but was...wait for it...4mm out.... now if I run a G29 z-.3 the bed and the Z axis motors can be seen to be actively compensating and the nozzle is kissing the bed nicely..... I thought the G29 z parameter wasn't supported ?

[james94jeans2]

I think the value for Z must be bigger than the Z_HOME_SEARCH value in the config otherwise you will be off and may kiss the bed.

EDIT: I'm sorry wrong command, thought of M420 Z.
Are you using Z-fade?

[rhinorap]

@james94jeans2 - admittedly I was trying to force it to do something out of spec - due to overwhelming frustration.

Oddly the sample output does not report a +1mm deviation, but it is definitely there after probing.
In a "raw" G29 call I get the results:
13:40:12.353 : Bilinear Leveling Grid:
13:40:12.353 : 0 1 2
13:40:12.358 : 0 +0.42 +0.20 +0.62
13:40:12.358 : 1 +0.61 +0.32 +0.82
13:40:12.361 : 2 +0.94 +0.06 +0.65

And calling a g1 z0 puts the nozzle appx 1mm above the bed ( and has active correction to hold it there)

However, if I call G29 z4 (as an example) I get:
13:43:07.975 : 0 1 2
13:43:07.975 : 0 +4.18 +3.81 +4.28
13:43:07.979 : 1 +4.31 +4.03 +4.50
13:43:07.979 : 2 +4.57 +3.87 +4.34
And as we'd expect, i'm now 4mm above the bed and actively corrected.

But with -.3 correction:
13:54:33.315 : Bilinear Leveling Grid:
13:54:33.315 : 0 1 2
13:54:33.315 : 0 -0.06 -0.39 +0.12
13:54:33.319 : 1 +0.09 -0.18 +0.25
13:54:33.319 : 2 +0.35 -0.38 +0.13

I'm at my appx z home position actively corrected.

Same happens with G29 Sn parameter.
I think this is the snippet from Marlin_Main under the G29 scripting ( line 4013):

#if ENABLED(AUTO_BED_LEVELING_BILINEAR)
float zoffset = zprobe_zoffset;
if (code_seen('Z')) zoffset += code_value_axis_units(Z_AXIS);
Question is, if a G29 is called with no suffix, does the Z_Axis hold a value that the mesh is applying during it's final calculations?

[Bob-the-Kuhn]

Short answer - yes.

The G29 calculations are always applied unless the dry run flag is set. None of the G29 parameters affect this except G29 D.

If you need to use G29 Zxx to get your Z0 height set correctly then you need to update your zprobe_zoffset value & save it. Feeler/slip gauges will get you close but zprobe_zoffset usually needs to be tweaked a bit based on print results.

Don't worry about the absolute values in the grid report. The resulting Z0 position is all that matters. I'm running Z_DUAL_ENDSTOPS with Z homing set to +. After running G28 my Z0 is about 15mm above the bed. After running G29 the grid values are all in the -15 range but my Z0 position is perfect.

[rhinorap]

I thought so.

What's been throwing me out it that my zprobe_offset is set bang on as homing puts it where i want it.
I'm guessing that i'll just have to remember to not send g1 z0 with the adjusted value ( I'm sort of sick of replacing my kapton :-) ).

Upside is I now have a system that i'm confident will prove itself tomorrow when I run a test print.

SO, SO SO much better than Repetier. A bit of a pain to configure in some ways ( the repetier config tool made me lazy!!).

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