[FR] HOMING_BACKOFF_MM confused with Z_AFTER_PROBING

[ruggb]

bugfix-2.0.x.9e8021d

in config...h
#define Z_AFTER_PROBING 10

in config...adv.h
#define HOMING_BACKOFF_MM { 0, 0, 0 }
when homed, nozzle RAISES 10 mm.
I expect it to stay at Z0

If I set #define Z_AFTER_PROBING 0
when homed nozzle stays at Z0

I didn't test it the other way round, but it would appear that homing is using the wrong variable.
So maybe probing is also using the wrong variable, maybe not.

I do have a nozzle probe defined and it appears that in G28.cpp & G29.cpp

    #if HOMING_Z_WITH_PROBE && defined(Z_AFTER_PROBING)
      move_z_after_probing();

should be qualified differently.

configs.zip

[ruggb]

I set Z_AFTER_PROBING = 5 and HOMING_BACKOFF_MM { 0, 0, 20 }
G28 or home Z will home Z then backoff to 20 then go to 5

So, it looks like Z_AFTER_PROBING is getting called after a straight Z home. The Z home during probing does not do the backoff and does end at 5, the Z_AFTER_PROBING height.

I have a nozzle mounted Piezo probe/endstop connected to the Z_MIN pin so it does not use a custom probe pin.

[ruggb]

This appears dead in the water. Has anyone looked at this?

[boelle]

@thinkyhead @shitcreek might have time at some point

[ruggb]

Just by the operation, Z_AFTER_PROBING appears to be getting handled in the Z home routine but without testing if the home was called from a probing routine or from a G28. If G28 calls the Z home, after it is homed, G28 backs off Z. So, I would think that a backoff sub should test which one should be done (it is only one) and not have it in the home routine. Just my guess.

[shitcreek]

When you home Z with a probe, it qualifies as probing. HOMING_BACKOFF_MM is redundant imo especially if you are also using MANUAL_(XYZ)_HOME_POS. I'd either not use HOMING_BACKOFF_MM or set Z to 0 or the same as Z_AFTER_PROBING.
I wouldn't say this is a bug. It's more of a feature request, which I would question which of the two should take precedence? Should we just add something along the line of:

#if HOMING_Z_WITH_PROBE && defined(Z_AFTER_PROBING) && defined(HOMING_BACKOFF_MM)
   constexpr xyz_float_t endstop_backoff = HOMING_BACKOFF_MM;
   if (endstop_backoff[Z_AXIS] <= Z_AFTER_PROBING)
      move_z_after_probing();
#endif

[boelle]

so maybe rename this one to a FR and rename the title?

[ruggb]

@shitcreek @boelle This is NOT a feature request. Here is why.

I set Z_AFTER_PROBING = 0 and HOMING_BACKOFF_MM { 0, 0, 20 }
If I HOME with G28 or home Z it will HOME Z then backoff to 20.
I set Z_AFTER_PROBING = 5 and HOMING_BACKOFF_MM { 0, 0, 0 }
If I HOME with G28 or home Z it will HOME Z and stay on the bed.
If I run a probing routine it will end up at Z=5.
So far so good right?

However, I do not want the nozzle to end up on the bed with either Homing or probing,
So, I set Z_AFTER_PROBING = 5 and HOMING_BACKOFF_MM { 0, 0, 20 }
The HOMING with G28 or home Z will HOME Z then backoff to 20 then go to 5.
Z_AFTER_PROBING will probe then go to 5.

What makes you think that implementing the Z after probing height after HOMING is design intent?
By that logic you should implement Homing backoff after probing.

Yes, you should apply the requested Z rise after the proper function. Doing both after a HOME is a BUG.

[ruggb]

@boelle
This is still a problem in 2.0 released.
Z_AFTER_PROBING should do what it says == AFTER PROBING.
NOT after homing.
I understand probing homes Z, but you need a flag to tell it when to implement Z_AFTER_PROBING.

update:
It appears that removing this (about line 424) from G28 fixes the problem, but I have not fully tested it yet.
#if HOMING_Z_WITH_PROBE && defined(Z_AFTER_PROBING)
move_z_after_probing();
#endif

Now it implements only backoff for homing and Z_AFTER_PROBING only after probing

[ruggb]

@boelle Is this EVER going to get fixed?
The move_z_after_probing(); on line 419 in current bugfix e3b0275 should NOT be implemented for a calibrate G28 homing. HOMING & PROBING are different.

Logically, removing it will affect no one because it is for PROBING not HOMING.
I commented out that whole IF statement (418, 419, 420) and it works for me on my CoreXY with a nozzle probe/endstop using Zmin pin

[boelle]

ask @thinkyhead or @shitcreek not me

[ruggb]

@thinkyhead or @shitcreek

Is this EVER going to get fixed?
The move_z_after_probing(); on line 419 in current bugfix e3b0275 should NOT be implemented for a calibrate G28 homing. HOMING & PROBING are different.

Logically, removing it will affect no one because it is for PROBING not HOMING.
I commented out that whole IF statement (418, 419, 420) and it works for me on my CoreXY with a nozzle probe/endstop using Zmin pin

[blackus3r]

I'm not sure, if I have the same problem, but I found this issue after searching for Z_AFTER_PROBING.
I also have a piezo probe sensor and if I set the Z_AFTER_PROBING greater then 0 (at the moment it is set to 2) the second G28 will end in a "Failed homing".
If I set Z_AFTER_PROBING to 0 everything is working fine. I can execute G28 several times, but If I set this value, the second G28 will always fail.
The same error appears with 'HOMING_BACKOFF_MM { 0, 0, 2 }' and Z_AFTER_PROBING 0

[tatusah]

You could use Z_PROBE_END_SCRIPT to set the height and do all kinds of tricks that apply only to probing as that is not run with G28.

[ruggb]

@blackus3r It does not sound like the same issue. However, I recommend implementing the fix I have first. I am not sure why @thinkyhead is not addressing this, but..........
My piezo nozzle probe/endstop it sensitive enough that if I have a 40mm part fan on it will fail. The extruder fan is on all the time and it gets by with that but it is 30mm and runs less than full speed. I also had to implement the delay to let XY movement settle out, otherwise Z home would fail on a G28. I am getting a std dev of 0.002 and a range of 0.009 on my probe repeatability.

[boelle]

we could make a PR... i could even make it

i just need to know precise what file to change and what to change

[boelle]

please add @ in front of my username to get my attention

[ruggb]

@boelle
this is from the latest bugfix = bugfix-2.0.x.899db41
2 hours ago
file is G28.cpp
line 418 thru 420
418 #if HOMING_Z_WITH_PROBE && defined(Z_AFTER_PROBING)
419 move_z_after_probing();
420 #endif
this should not be implemented for HOMING Z only for probing.
At least it works for me and my CoreXY printer.
I have all three lines commented out.

[ruggb]

@boelle Hey, I just uploaded that build.
I want to congratulate someone for messing with BABYSTEPPING again.
Now they have the display reading xxx.xx instead of xx.xxx for BABY stepping. Like someone is going to sit there turning the nob to get to 100.xx. Instead, it takes multiple clicks to get to 000.01 because 000.00x doesn't show. There is a reason it is called BABY stepping.
Is there a config I can change to get back to .xxx instead of .xx?

[InsanityAutomation]

@ruggb change the limits to 9 instead of 20. Was forced due to a rollover issue. Now looks at limit to determine display. Also move amount is not affected by the display change....

[ruggb]

@InsanityAutomation
Thanks, but can you give me a little more info
what "LIMITS"?
What file?
What line?

[InsanityAutomation]

Configuration.h

// For M851 give a range for adjusting the Z probe offset
#define Z_PROBE_OFFSET_RANGE_MIN -20
#define Z_PROBE_OFFSET_RANGE_MAX 20

See #16425 - with the 3 digit precision many users insisted on, values were getting rolled over and set incorrectly when over 10. So now we look at the limit and give precision when we can otherwise itll work albeit not as precisely as some prefer.

[ruggb]

@InsanityAutomation
I'm confused! Are you saying that these defines affect the babystepping display?
And if I change it to a single digit the BS display will show 3 significant digits.

My probe IS the nozzle, so my range is 0, right?
Should I set them at +-0?

[InsanityAutomation]

Yes, its display only. If you set them to 9 or below, it will show 3 significant digits. 10 or more it shows 2. Setting to 0 will mean you cant babystep at all, so maybe a reasonable limit like 5.

[ruggb]

@InsanityAutomation
I set it to 0 and now have BS back == to 4 digits. Of course, the 4th digit is always 0.
Would it change if I set it to 9?

[ruggb]

But BS does work at 0. Since that 4th digit is useless and I don't need it, I will change it to 5 maybe. That number is meaningless to me anyway.
thanks

[InsanityAutomation]

The amount it changes is up to the same value it has always been, BABYSTEP_MULTIPLICATOR_Z in config_adv and the actual steps/mm as that refers to a step amount based on the lcd encoder increments.

[ruggb]

Yes, mine increments 0.005/step.
What would cause BS TOTAL to be different than the BS display?
It just seems like that is redundant.

[InsanityAutomation]

Iff M851 and babystepping are not combined it is not a retained number.

[boelle]

if changes on how marlin behaves an FR is in order here

code is doing as it is written

problem here is that it does 2 steps but there should be an option to switch between or one should be removed

if homing with probe, probe should be used
otherwise homing backoff

[ruggb]

@boelle
Obviously, I am not communicating with you.
Maybe you can try explaining to me what you think I am saying so I can correct you.

When the system HOMES Z, it is NOT PROBING, it is HOMING.
Placing code in the HOMING routine to set Z AFTER PROBING is totally invalid.

Doing so causes the system to do HOMING BACKOFF after HOMING, then do Z AFTER PROBING.
The result is that Z will never end up at HOMING BACKOFF, because Z AFTER PROBING cancels it out.

I cannot be much clearer. The code is definitely "doing as it is written". That is not the problem.
IT IS WRITTEN WRONG!

And I am tired of trying to educate you, so I will just ignore this and keep modifying MY file to make it work as it should.
thank you.

[InsanityAutomation]

Ill be frank here. I understand the issue is it is executing both and only one of these 2 functions should be executed. The reason nobody has touched even that much of it is because of the combative attitude. You catch more flies with honey than vinegar as they say.

From one side, any action done with the probe is probing. It is published in many places to set the desired z after homing there with a probe. It is controlled not just by the presence of a probe, but by the flag of if you are actually using the probe to home. By that logic, the number here should override the number in homing backoff and only a single move executed. If you enable homing backoff and put a number that is not 0 or matching the z after probing, a sanity check should stop you and warn of an inconsistent configuration.

This could all be done in an hour. Probably would have been already if the tone here didnt send anyone capable of doing it running.

[boelle]

IT IS WRITTEN WRONG!

then its a FR

And I am tired of trying to educate you

now that i'm close to 42years it might be that what is left of the big grey jelly mass on top of my shoulders have calcified up etc, but i dont think i ever asked for this

but just an old mans guess here that this issue will hang around for much longer now

[Roxy-3D]

@ruggb I'm out of town and not really able to test any code changes I make. But if this doesn't get resolved to your satisfaction in 2 or 3 weeks... Please send me a message. I'll personally work with you to get the desired behavior.

(I value your contributions finding issues and working through them! And I think I've noticed what may be the same strange behavior when homing and starting a print. )

[ruggb]

@InsanityAutomation
First post Nov 3 2019
today Jan 31 2020
3 months trying to get someone to address this and getting no logical response.
Yea, I am frustrated. Fortunately, I can fix it myself for my printer. It is just a pita to have to do it all the time.

Bottom line, you also still do not seem to understand the issue.

"From one side, any action done with the probe is probing. It is published in many places to set the desired z after homing there with a probe. It is controlled not just by the presence of a probe, but by the flag of if you are actually using the probe to home. By that logic, the number here should override the number in homing backoff and only a single move executed. If you enable homing backoff and put a number that is not 0 or matching the z after probing, a sanity check should stop you and warn of an inconsistent configuration."

Those are two separate items. There is no connection. When you home, you execute HOMING_BACKOFF. You DO NOT then execute Z_AFTER_PROBING. There is nothing to sanity check. After homing I want the nozzle at 20. After probing I want the nozzle at 5.
Take those 3 lines out of G28 and it will not be a 1 hour job. == about 30 seconds. Include it with your next pull and it is done.

I think you should drop this issue, because I am afraid you will mess it up more than it is, since you do not understand.

The "strange behavior when homing and starting a print. " @boelle notices is EXACTLY a result of this BUG. The printer will home Z then go to 20 (HOMING BACKOFF), then go to 5 (Z AFTER PROBING, except it wasn't probing, so it should not DO that), then start the print.

[boelle]

please dont @ me, your attitude is to toxic for me

[thinkyhead]

@ruggb —

Generally speaking, HOMING_BACKOFF_MM is only needed if staying up against endstops is a problem. The Z value in that array should probably just be 0 when homing with a probe. It's not treated in the code quite the same as a "z raise" though I don't think it's a big problem if it is used as such.

I see, as you point out, that the Z_AFTER_PROBING value is applied in G28 when the Z probe is used for homing. It's also applied after G30 and (oddly) in M402 which doesn't even probe.

At the moment there is no separate option in Marlin for a raise after homing. Of course, this is easy enough to add. The code will be quite straightforward. I'll push something shortly for you to try out.

[thinkyhead]

See if #16755 is useful.

[ruggb]

@thinkyhead
If it works like I think it should work when I remove 3 lines of code in G28 why must you create a separate option to do what is already there? What am I missing?
HOMING_BACKOFF == Z_AFTER_HOMING are the same thing as far as I can tell. In fact, I think it was called that at one time.

[thinkyhead]

What am I missing?

Gratitude?

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