G28 homing problem

[Slavulj]

Hello,

i got problem while homing with G28
im homing with inductive sensor and my setup are:

#define Z_RAISE_PROBE_DEPLOY_STOW 0
#define Z_RAISE_BETWEEN_PROBINGS 5
#define MIN_Z_HEIGHT_FOR_HOMING 5

problem is when i home it,
it up z for 5mm, home x, home y, go to the mid(coz of Z_SAFE_HOMING)
and again up z for 5mm, i dont want to go for 5mm more

but when i make Z_RAISE_BETWEEN_PROBINGS to 0
it goes how i want:
up z for 5, home x, home y, go mid, home z
BUT then autolevel does not work because there is no raise between probing

when i make MIN_Z_HEIGHT_FOR_HOMING to 0
it does not rise up z on start which i want

i use Marlin 1.1.0-RC7

[Slavulj]

had to enable this

#define PROBE_DOUBLE_TOUCH

to get it like i want
with this settings

#define Z_RAISE_PROBE_DEPLOY_STOW 0
#define Z_RAISE_BETWEEN_PROBINGS 0
#define MIN_Z_HEIGHT_FOR_HOMING 5

[thinkyhead]

@Slavulj What kind of machine do you have? What kind of bed leveling are you using? Do you always home Z with a probe, or do you have a Z min endstop? And, do you still see the incorrect behavior when using RCBugFix without your workaround applied?

@Roxy-3D @jbrazio @AnHardt Apparently in G28 we're getting an extra raise in the homing of Z, maybe just in Z_SAFE_HOMING. Where do we suppose this extra raise is coming from? Have we incorrectly set the current position or forgotten to update it in this procedure?

[thinkyhead]

@Slavulj If you enable DEBUG_LEVELING_FEATURE you can then use the command M111 S255 to get Marlin to print extra debugging messages to the serial console for homing and leveling. In particular, I would be interested to see what the "current_position" is at the point when G28 calls "set_probe_deployed(true)." It should be at the MIN_Z_HEIGHT_FOR_HOMING already and should not do any additional raise.

The reason that there is any raise at all is because Z_RAISE_BETWEEN_PROBINGS is used as a baseline for probe deployment also. This is ensured by the conditionals:

#if Z_RAISE_BETWEEN_PROBINGS > Z_RAISE_PROBE_DEPLOY_STOW
  #define _Z_RAISE_PROBE_DEPLOY_STOW Z_RAISE_BETWEEN_PROBINGS
#else
  #define _Z_RAISE_PROBE_DEPLOY_STOW Z_RAISE_PROBE_DEPLOY_STOW
#endif

[Roxy-3D]

Apparently in G28 we're getting an extra raise in the homing of Z, maybe just in Z_SAFE_HOMING. Where do we suppose this extra raise is coming from? Have we incorrectly set the current position or forgotten to update it in this procedure?

I can confirm it is there. It is in the UBL code that I forked from RC-6 on July 4th. It is annoying as hell! (especially since my FolgerTech-2020 printer has a super slow Z Axis.) But I haven't complained because I know it will get fixed soon enough and I'll just grab the fix and update the UBL branch with it. I apologize, but even though it has been annoying me, I have spent zero time looking for it.

I can tell you this... After a reboot, the system does a raise (because it needs to do it) when a G28 is given. The system homes X & Y. but then... It still doesn't know where the Z is located. So it does YET ANOTHER raise before it deploys the Z probe. It doesn't seem to remember it already did a raise before it did the X & Y home.

That might be enough information to find it????

[thinkyhead]

@Roxy-3D I'm not convinced by your analysis and still need to see the logs. Could you perhaps try DEBUG_LEVELING_FEATURE with M111 S255 and post your results?

[Roxy-3D]

Yes. But remember... I'm working with the code as it was July 4th.
I think I might be wrong about the double raise. I just did it with a freshly reset machine and with an already homed machine. So there are two G28's in this log. I'll have to pay more attention and see if I can catch it doing a double raise. If so, I'll capture a log and post it. But here is what it is doing right now.

Maybe what I'm seeing is it raising too high??? It is going up to Z=18 and I really don't need that much height. Maybe that is what is annoying me???? Because my Z_RAISE_ numbers:

#define Z_RAISE_PROBE_DEPLOY_STOW 5 // Raise to make room for the probe to deploy / stow
#define Z_RAISE_BETWEEN_PROBINGS 5  // Raise between probing points.

Also... I have made some minor changes to G28. So if the log can't possibly happen in the RC7 branch, it may be you have to look at G28 in devel_ubl.

Connecting...
start
Printer is now online.
Log moved to subsequent post....

[thinkyhead]

Is that a log from RCBugFix? That's the version I would want to see. And preferably just the part where it's screwing up, rather than the whole thing.

[Roxy-3D]

That is from the UBL branch which was forked from RCBugFix on July 4th. I do not have a 'Pure' RCBugFix to show you because right now I'm entirely focused on UBL. But I can tell you I had RCBugFix running in its pure form on July 4th with nothing else in it, and it was doing this 'extra' raise at that point in time with no modifications to the code.

I'll cut down the size of the log and post that next. I believe the extra height is showing up immediately after the first Z-Probe is done. But I'll watch and confirm that....

[sarf2k4]

I would like to add my side of bug as well

I enabled raise z before homing and uses stow feature as well for ABL as attached by the following config file

I am using prusa i3 variant with a z max endstop setup.

During homing, marlin would raise the z axis twice, first for the z raise before home, second is for stow/deploy command. During the g28 testing, I manually pressed the z max endstop with my hand, after the z raise before home initiated, I released it it worked okay followed with stoe/deploy procedure. Then here comes the next one, I press the z max endstop right before the stow/deploy (after z raise before home), it didn't raise (this isn't the main issues) and it goes down to use the servo mounted probe.

After the probe detected there's a contact, it just stops there and stow away the servo probe, leaving the display value of z axis at about +17mm above the bed but physically it's at around 2-3mm above the bed. Tried this three times in a row

Configuration.txt

[Roxy-3D]

That is interesting! Both @sarf2k4 and I are seeing similar things. His nozzle is going to +17mm and mine is about 18mm. Here is a G28 log with all the extra debugging cut out. In my case, the very first thing it does is go to 18.3mm and after the Z-Probe operation, it ends up at 16.3mm.

Debug Log

Connecting...
start
Printer is now online.
Using tool 0.
echo:Marlin 1.1.0-RCBugFix
echo: Last Updated: 2016-04-27 12:00 | Author: (Folger Tech, 8 i3 Prusa Config)
Compiled: Aug  3 2016
...
echo:Z-Probe Offset (mm):
echo:  M851 Z-11.30
servo init angle(80)
>>> gcode_T
BEFORE > current_position: (0.00, 0.00, 0.00)
AFTER > current_position: (0.00, 0.00, 0.00)
<<< gcode_T
echo:Active Extruder: 0
>>> G28
SENDING:G28
>>> gcode_G28
setup_for_endstop_or_probe_move > current_position: (0.00, 0.00, 0.00)
do_probe_raise(7.00)
do_blocking_move_to: (0.00, 0.00, 18.30)
>>> homeaxis(0)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (0.00, 0.00, 18.30)
>>> set_axis_is_at_home(0)
> home_offset[axis]==0.00 > current_position: (0.00, 0.00, 18.30)
<<< set_axis_is_at_home(0)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 18.30)
<<< homeaxis(0)
> homeX > current_position: (0.00, 0.00, 18.30)
>>> homeaxis(1)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (0.00, 0.00, 18.30)
>>> set_axis_is_at_home(1)
> home_offset[axis]==0.00 > current_position: (0.00, 0.00, 18.30)
<<< set_axis_is_at_home(1)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 18.30)
<<< homeaxis(1)
> homeY > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING >>>
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING > home_all_axis > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING > home_all_axis > destination: (63.00, 97.00, 18.30)
>>> homeaxis(2)
> set_probe_deployed > current_position: (63.00, 97.00, 18.30)
deploy: 1do_probe_raise(5.00)
do_blocking_move_to: (63.00, 97.00, 18.30)
sync_plan_position > current_position: (63.00, 97.00, 0.00)
sync_plan_position > current_position: (63.00, 97.00, 0.00)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (63.00, 97.00, 0.00)
>>> set_axis_is_at_home(2)
> zprobe_zoffset==-11.30
> home_offset[axis]==0.00 > current_position: (63.00, 97.00, 11.30)
<<< set_axis_is_at_home(2)
sync_plan_position > current_position: (63.00, 97.00, 11.30)
> AFTER set_axis_is_at_home > current_position: (63.00, 97.00, 11.30)
> set_probe_deployed > current_position: (63.00, 97.00, 11.30)
deploy: 0do_probe_raise(5.00)
do_blocking_move_to: (63.00, 97.00, 16.30)
do_blocking_move_to: (63.00, 97.00, 16.30)
<<< homeaxis(2)
<<< Z_SAFE_HOMING
> (home_all_axis || homeZ) > final > current_position: (63.00, 97.00, 16.30)
sync_plan_position > current_position: (63.00, 97.00, 16.30)
clean_up_after_endstop_or_probe_move > current_position: (63.00, 97.00, 16.30)
<<< gcode_G28

[Blue-Marlin]

@sarf2k4
Let's take that apart:

I enabled raise z before homing and uses stow feature as well for ABL as attached by the following config file

#define USE_XMIN_PLUG
#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG
//#define USE_XMAX_PLUG
//#define USE_YMAX_PLUG
#define USE_ZMAX_PLUG

#define X_MIN_ENDSTOP_INVERTING false
#define Y_MIN_ENDSTOP_INVERTING false
#define Z_MIN_ENDSTOP_INVERTING false
#define X_MAX_ENDSTOP_INVERTING true 
#define Y_MAX_ENDSTOP_INVERTING true 
#define Z_MAX_ENDSTOP_INVERTING true // your z-max-endstop works differently?
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

#define Z_ENDSTOP_SERVO_NR 0
#define Z_SERVO_ANGLES {12,90}
#define X_PROBE_OFFSET_FROM_EXTRUDER -44
#define Y_PROBE_OFFSET_FROM_EXTRUDER -8 
#define Z_PROBE_OFFSET_FROM_EXTRUDER -2.85
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_RAISE_PROBE_DEPLOY_STOW 15
#define Z_RAISE_BETWEEN_PROBINGS 5
#define MIN_Z_HEIGHT_FOR_HOMING 10

I am using prusa i3 variant with a z max endstop setup.

If you want to use the z-max endstop for homing simply set #define Z_HOME_DIR 1

During homing, marlin would raise the z axis twice, first for the z raise before home, second is for stow/deploy command.

Right, if using a probe to home to z-min.

During the g28 testing, I manually pressed the z max endstop with my hand, after the z raise before home initiated, I released it it worked okay followed with stow/deploy procedure.

Why did you press the z-max-endstop? What should it be good for?

Then here comes the next one, I press the z max endstop right before the stow/deploy (after z raise before home), it didn't raise (this isn't the main issues) and it goes down to use the servo mounted probe.

Obviously it can not rise. The z-max endstop is triggered and prevents a rise. That's what it is for.
It prevents the move, but the planner thinks it has been done. (An old problem)

After the probe detected there's a contact, it just stops there and stow away the servo probe, leaving the display value of z axis at about +17mm above the bed but physically it's at around 2-3mm above the bed. Tried this three times in a row

z goes down to ~ 2.85 where the probe triggers. If you still hold the z-max-endstop z can't rise, but the planner is not informed and thinks the move has been done. 15+~ 2.85 = ~17.

So everything works as designed but your finger on the z-max-endstop.

Repeating this can't give a different result. Only the first raise will not be tried because the planner now thinks z is high enough to move in x/y-direction.

For the answer to the question why these last stow move ends at (Z_RAISE_PROBE_DEPLOY_STOW + ~Z_PROBE_OFFSET_FROM_EXTRUDER) and not at Z_RAISE_PROBE_DEPLOY_STOW ask @thinkyhead

[Blue-Marlin]

@Roxy-3D
From what branch, at what date is your log? RCBugFix at 'Independence Day' may have had a problem with the raises. In fact #4217 was one of the first merges after your split.

[Roxy-3D]

I'll see if putting 4217 into it helps! The extra high raise is annoying, but it isn't stopping me from doing my work. That is why I haven't been complaining or spending time on it.

[Blue-Marlin]

However your end height 16.3 is (Z_RAISE_PROBE_DEPLOY_STOW + Z_PROBE_OFFSET_FROM_EXTRUDER)

[sarf2k4]

The pins for z max endstop are correct and working fine, i use mechanical manually wired switch.

For the z max endstop, i required it so that the z axis will not crash on my z tower bracket for the z raise before homing feature if the z axis were to be near to the tower bracket after it turned off.

After i did press the endstop manually to test out if the z endstop works fine and will not ignore during G28 issued, this is crucial to check if marlin are supposed to stop whem the endstop triggered or not. Z max endstop are there as described in the above paragraph.

During the second raise which is the stow/deploy raise, i did this for the scenario what if rhe z max endstop were to be triggered during this procedure, and i also released my hand from the endstop after seeing the z axis started to descend to get the z axis position.

To me, the most important part is not to let the axis crash to either direction especially on z axis, it can be a pain once it crashed.

I will give it another test later after finish printing.

[thinkyhead]

It still doesn't know where the Z is located.
So it does YET ANOTHER raise before it deploys the Z probe.

This is the statement that annoys me. Because the machine only initializes with Z=0, but after that we can track relative movement. So, after some raise, the result might be Z=5. If we tell Z to raise to 5 again, it shouldn't, because (wrong or not) it now has Z=5. If there's some additional raise happening, it sounds like it's because some piece of code is setting Z to zero again. Which is wrong. When we do homing, we should always preserve the Z coordinate, even if it is wrong, and do everything relative to that. But some contributors (see MBL with its MESH_HOME_SEARCH_Z setting, for example) have had the attitude that these coordinates don't matter, so we can do whatever we want during homing or leveling. Well, they do matter, and we can't just set them to some value for convenience at any moment.

[Roxy-3D]

(see MBL with its MESH_HOME_SEARCH_Z setting, for example) have had the attitude that these coordinates don't matter, so we can do whatever we want during homing. Well, they do matter, and we can't just set them to some value for convenience at any moment.

That is a good clue! I'm all set to debug this. I crossed #4217 over and it fixed the extra raise, but it caused some other strange movement that I don't think is safe. [I'm not being critical of #4217. The problem is it wasn't done and checked out with my changes.]

In the case of UBL, at its foundation level, it is a High Resolution Mesh. So most places that had #ifdef ENABLED(MESH_LEVELING) turned into #ifdef ENABLED(UNIFIED_BED_LEVELING_FEATURE) and are still in the code. G28 has a number of places with old MESH_LEVELING stuff still active.

Your hint, along with the DEBUG_LEVELING stuff should let me find it fairly quickly.

[thinkyhead]

@Roxy-3D #4217 alone probably isn't good. There was a followup #4235. And #4231 might also help.

[Blue-Marlin]

It still doesn't know where the Z is located.
So it does YET ANOTHER raise before it deploys the Z probe.

MIN_Z_HEIGHT_FOR_HOMING is sufficient to not touch the bed/clamps when homing x/y.
If you want to probe you need to be higher (Z_RAISE_PROBE_DEPLOY_STOW).
If we would always rise to Z_RAISE_PROBE_DEPLOY_STOW, the first time, this would be unnecessary high for homing x/y only.
The plan is to make the minimal needed rises.
The second rise then should be to Z_RAISE_PROBE_DEPLOY_STOW - (Z_RAISE_PROBE_DEPLOY_STOW - MIN_Z_HEIGHT_FOR_HOMING) lenght.

I admit it's more, but that's the strangeness of do_probe_raise().

[Blue-Marlin]

The concept is easy. We have 3 levels:

• MIN_Z_HEIGHT_FOR_HOMING -> the nozzle can't hit anything when moved in x/y direction.
• Z_RAISE_BETWEEN_PROBINGS -> a deployed probe can't hit anything when moved in x/y direction.
• Z_RAISE_PROBE_DEPLOY_STOW -> a probe can be safely deployed/stowed everywhere.

The names do not reflect their function very well, but that's a discussion i gave up.

[thinkyhead]

The names do not reflect their function very well, but that's a discussion i gave up.

Of course, they could be changed to Z_HEIGHT_* but at the time when these changes were being made I just didn't feel like renaming yet more options as we're trying to write up documentation. But it seems that users are adapting to the renaming of options okay, with the help of sanity checking. So I suppose we can still rename these before final release.

So it does YET ANOTHER raise before it deploys the Z probe.

If you want to probe you need to be higher

Well, the bug we're looking for doesn't just raise by the difference between MIN_Z_HEIGHT_FOR_HOMING and Z_RAISE_PROBE_DEPLOY_STOW. It seems to be doing an additional raise by Z_RAISE_PROBE_DEPLOY_STOW over the current position, giving a final result of MIN_Z_HEIGHT_FOR_HOMING + Z_RAISE_PROBE_DEPLOY_STOW.

[Blue-Marlin]

@thinkyhead
What i do see, is a additional raise by Z_PROBE_OFFSET_FROM_EXTRUDER, introduced in do_probe_raise().

Z_HEIGHT_* is redundant. HEIGHT_* is sufficient.

[Roxy-3D]

What i do see, is a additional raise by Z_PROBE_OFFSET_FROM_EXTRUDER, introduced in do_probe_raise().

Yes! I was going to point that out as I saw Blue-Marlin's comment show up:
Check out this log....

echo:Z-Probe Offset (mm):
echo: M851 Z-11.30 <----<<< This number plus the 7mm for MIN_Z_HEIGHT_FOR_HOMING gets us to 18.3mm

servo init angle(80)

>>> gcode_T
BEFORE > current_position: (0.00, 0.00, 0.00)
AFTER > current_position: (0.00, 0.00, 0.00)
<<< gcode_T
echo:Active Extruder: 0
>>> G28
SENDING:G28
>>> gcode_G28
setup_for_endstop_or_probe_move > current_position: (0.00, 0.00, 0.00)
do_probe_raise(7.00)
do_blocking_move_to: (0.00, 0.00, 18.30)

Full log here:

>>> G28
SENDING:G28
Disconnected.
Connecting...
start
Printer is now online.
echo:Marlin 1.1.0-RCBugFix
echo: Last Updated: 2016-04-27 12:00 | Author: (Folger Tech, 8 i3 Prusa Config)
Compiled: Aug  3 2016
echo: Free Memory: 3171  PlannerBufferBytes: 1232
echo:V30 stored settings retrieved (263 bytes)
...
echo:  M200 D0
echo:Z-Probe Offset (mm):
echo:  M851 Z-11.30
servo init angle(80)
>>> gcode_T
BEFORE > current_position: (0.00, 0.00, 0.00)
AFTER > current_position: (0.00, 0.00, 0.00)
<<< gcode_T
echo:Active Extruder: 0
>>> G28
SENDING:G28
>>> gcode_G28
setup_for_endstop_or_probe_move > current_position: (0.00, 0.00, 0.00)
do_probe_raise(7.00)
do_blocking_move_to: (0.00, 0.00, 18.30)
>>> homeaxis(0)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (0.00, 0.00, 18.30)
>>> set_axis_is_at_home(0)
> home_offset[axis]==0.00 > current_position: (0.00, 0.00, 18.30)
<<< set_axis_is_at_home(0)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 18.30)
<<< homeaxis(0)
> homeX > current_position: (0.00, 0.00, 18.30)
>>> homeaxis(1)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (0.00, 0.00, 18.30)
>>> set_axis_is_at_home(1)
> home_offset[axis]==0.00 > current_position: (0.00, 0.00, 18.30)
<<< set_axis_is_at_home(1)
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 18.30)
<<< homeaxis(1)
> homeY > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING >>>
sync_plan_position > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING > home_all_axis > current_position: (0.00, 0.00, 18.30)
> Z_SAFE_HOMING > home_all_axis > destination: (63.00, 97.00, 18.30)
>>> homeaxis(2)
> set_probe_deployed > current_position: (63.00, 97.00, 18.30)
deploy: 1do_probe_raise(5.00)
do_blocking_move_to: (63.00, 97.00, 18.30)
sync_plan_position > current_position: (63.00, 97.00, 0.00)
sync_plan_position > current_position: (63.00, 97.00, 0.00)
> endstops.enable(false)
> endstops.enable(true)
> TRIGGER ENDSTOP > current_position: (63.00, 97.00, 0.00)
>>> set_axis_is_at_home(2)
> zprobe_zoffset==-11.30
> home_offset[axis]==0.00 > current_position: (63.00, 97.00, 11.30)
<<< set_axis_is_at_home(2)
sync_plan_position > current_position: (63.00, 97.00, 11.30)
> AFTER set_axis_is_at_home > current_position: (63.00, 97.00, 11.30)
> set_probe_deployed > current_position: (63.00, 97.00, 11.30)
deploy: 0do_probe_raise(5.00)
do_blocking_move_to: (63.00, 97.00, 16.30)
do_blocking_move_to: (63.00, 97.00, 16.30)
<<< homeaxis(2)
<<< Z_SAFE_HOMING
> (home_all_axis || homeZ) > final > current_position: (63.00, 97.00, 16.30)
sync_plan_position > current_position: (63.00, 97.00, 16.30)
clean_up_after_endstop_or_probe_move > current_position: (63.00, 97.00, 16.30)
<<< gcode_G28
Disconnected.

[Blue-Marlin]

@thinkyhead
I agree we did agree about not changing the names, but not about changing the definition.
Sorry for using the back-door. ;-)

[Roxy-3D]

echo:Z-Probe Offset (mm):
echo: M851 Z-11.30 <----<<< This number plus the 7mm for MIN_Z_HEIGHT_FOR_HOMING gets us to 18.3mm

See how easily I get led astray? Personally, I think we should get rid of all the 'RAISE' text in the names. HEIGHT is what we really are doing now.

[thinkyhead]

additional raise by Z_PROBE_OFFSET_FROM_EXTRUDER, introduced in do_probe_raise

That would explain why the raise is higher than anticipated.

But I think the rationale for adding -zprobe_zoffset still makes sense. (It ensures that a raise of zero still clears the probe. Thus the height is not relative to the nozzle touching the bed, but relative to the probe's Z trigger-point.)

In other words, I thought we should add -zprobe_zoffset rather than trust the user to make sure they take account of the probe distance. Is this too much hand-holding?

Perhaps it makes better sense to just make Z_PROBE_OFFSET_FROM_EXTRUDER the minimal raise, rather than adding it to the Z-before-probing-height value.

Or, it may make sense for z homing (when a probe will be used) to also add -zprobe_zoffset so that these two raises have parity. We then have to document the fact that these heights are relative to the triggered probe and not relative to Z=0.

[thinkyhead]

echo: M851 Z-11.30 <----<<< This number plus the 7mm for MIN_Z_HEIGHT_FOR_HOMING gets us to 18.3mm

Here's a perfect example of what I mean. Roxy didn't make MIN_Z_HEIGHT_FOR_HOMING or Z_PROBE_OFFSET_FROM_EXTRUDER larger than 11.3 mm, but she should have (if she was assuming these constitute the total raise). If even the core developers don't know enough to set the raises higher than the probe distance, how can we expect average users to remember to do this?

[Blue-Marlin]

No. She should not!
There is no need to include Z_PROBE_OFFSET_FROM_EXTRUDER in MIN_Z_HEIGHT_FOR_HOMING. The probe should not be active before it is deployed.

[thinkyhead]

Am I missing something? If you deploy at 7mm height an inductive probe that triggers at 11mm above the bed, then it will be triggered right away. So you need to set your initial height over 11mm. If you have a servo probe that sits 11mm below the nozzle, you can't even deploy it at 7mm height. Thus we do need to enforce a minimum distance of Z_PROBE_OFFSET_FROM_EXTRUDER (and a little more), one way or another.

[Blue-Marlin]

Of c(our)se!
Z_RAISE_BETWEEN_PROBINGS should be at least that high. For a inductive/capacitive/IR probe Z_RAISE_PROBE_DEPLOY_STOW does not need to be higher.
We have always talked about the trigger point, not the blue/yellow/physical surface of the probe.

In case of a normal switch, where the lever is hanging down below its trigger point, is the problem of your thoughts. Z_PROBE_OFFSET_FROM_EXTRUDER is not enough.

[Roxy-3D]

In other words, I thought we should add -zprobe_zoffset rather than trust the user to make sure they take account of the probe distance. Is this too much hand-holding?

They way I see it... The way I understand things... Z-Probe-Offset isn't part of the behavior. That is so the machine can subtract that amount off of the probed point to know where the bed is. It has nothing to do with what height is needed to move around or deploy the probe.

Here's an example of what I mean. Roxy didn't make MIN_Z_HEIGHT_FOR_HOMING larger than 11.3 mm, but she should have. If even the developers don't know enough to set the raises higher than the probe distance, how can we expect average users to remember to do this?

Nobody told me I needed to do that. And I really don't need that. I have a cheap micro-switch from China with a little roller thingy on it. It can get depressed as it deploys and everything is fine. I don't need the nozzle to be so high it doesn't even touch the bed as it swings into position.

Am I missing something? If you deploy at 7mm height an inductive probe that triggers at 11mm above the bed, then it will be triggered right away.

I have a cheap micro-switch from China with a roller wheel on it. I don't have an inductive probe.

There is no need to include Z_PROBE_OFFSET_FROM_EXTRUDER in MIN_Z_HEIGHT_FOR_HOMING.

I think I agree with this statement. In the morning I'll yank that out of the do_probe_raise() and see if things are better for me. I may need to shift my numbers some because I've been cutting them back because of the 'extra' raise. But if we are going to move to a Z_HEIGHT type of name, I think they should be used by themselves.

In case of a normal switch, where the lever is hanging down below its trigger point, is the problem of your thoughts. Z_PROBE_OFFSET_FROM_EXTRUDER is not enough.

I think the users will find it easier to get setup if we are not combining and adding numbers together. I think in this case, we just want to use the MIN_Z_HEIGHT_FOR_HOMING number and not try to get tricky.

And I know this next statement is going to cause trouble. But my feelings are MIN_Z_HEIGHT_FOR_HOMING is 1mm for me. I just need the nozzle up off the bed. The Z_HEIGHT_TO_DEPLOY_PROBE should handle the Z homing part.

[thinkyhead]

Z_PROBE_OFFSET_FROM_EXTRUDER is not enough.

I presume we all know this, so didn't bother to mention it. But yes, all the more reason to use it as the bare minimum height.

[Blue-Marlin]

A try of rewording:

• MIN_Z_HEIGHT_FOR_HOMING -> the nozzle can't hit anything when moved in x/y direction.
• Z_RAISE_BETWEEN_PROBINGS -> a deployed probe can't hit or trigger anything when moved in x/y direction.
• Z_RAISE_PROBE_DEPLOY_STOW -> a probe can be safely deployed/stowed everywhere without triggering.

[Roxy-3D]

I presume we all know this, so didn't bother to mention it. But yes, all the more reason to use it as the bare minimum height.

I can live with what ever gets decided. But I need less than the Z_PROBE_OFFSET_FROM_EXTRUDER. The position of the roller on the switch is such that it can get into position just fine at less than that number.

[thinkyhead]

So does removing these lines from do_probe_raise solve everything?

if (zprobe_zoffset < 0)
  z_dest -= zprobe_zoffset;

[Roxy-3D]

@Blue-Marlin Your wording is good.

@thinkyhead I'm going to do just that in the morning and give it a try. I'll report back on that question in the morning.

[Roxy-3D]

MIN_Z_HEIGHT_FOR_HOMING -> the nozzle can't hit anything when moved in x/y direction.

I just need 1mm for this. I just want the nozzle up off the bed. Maybe this should be called MIN_Z_HEIGHT_FOR_HOMING_XY ?????

[thinkyhead]

I just need 1mm for this

When I was printing a lot of ABS this would have made troughs in the dried ABS slurry covering my bed. (I was a messy ABS printing fool.)

[Blue-Marlin]

@thinkyhead
I hope so.

if (zprobe_zoffset < 0)
      z_dest -= zprobe_zoffset;

is wrong anyway. If at all

      z_dest += abs(zprobe_zoffset);

but that is not recognizing hanging normal switches. ... Running in circles.

[thinkyhead]

z_dest += abs(zprobe_zoffset);

I think not. When the offset is positive, it's because the nozzle presses against something to trigger the "probe." It's not because there is something physically higher up. The nozzle is still at offset zero.

[Blue-Marlin]

I just need 1mm for this. I just want the nozzle up off the bed.

Everywhere. Regardless how much slope your bed has. Regardless if you are crossing a clamp.

[Blue-Marlin]

Sorry. 5:25am. Going to bed.

[thinkyhead]

Sleep! It's beer-o-clock here. 🍺

[Roxy-3D]

but that is not recognizing hanging normal switches. ... Running in circles.

And that is why a couple nicely named 'Z_HEIGHT_' things makes everything simple. You have Z_HEIGHT_TO_HOME_XY and Z_HEIGHT_TO_DEPLOY_Z_PROBE and maybe we need one more like Z_HEIGHT_BETWEEN_PROBES. The point is, by changing from RAISE to HEIGHT we are shifting from a relative to absolute coordinate system. We only need to specify a few absolute numbers and we can make the right thing happen.

[sarf2k4]

@makaira were right, I did hold the z max endstop after the probing, that's why the z axis didn't get raised.

Sorry for the false alarm on this one

[Roxy-3D]

Everything is behaving nicely for me with those lines commented out. I think we should consider propagating the changes to RC-7.

  inline void do_probe_raise(float z_raise) {
    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) {
        SERIAL_ECHOPAIR("do_probe_raise(", z_raise);
        SERIAL_ECHOLNPGM(")");
      }
    #endif
    float z_dest = home_offset[Z_AXIS] + z_raise;
//  if ((Z_HOME_DIR) < 0 && zprobe_zoffset < 0)
//    z_dest -= zprobe_zoffset;
    if (z_dest > current_position[Z_AXIS]) {
      do_blocking_move_to_z(z_dest);
    }

[thinkyhead]

How does this issue look now with the latest RCBugFix code? The raise options are now "height" options and work in the simplest manner, specifying the nozzle height over the bed, as elsewhere.

[Roxy-3D]

How does this issue look now with the latest RCBugFix code? The raise options are now "height" options and work in the simplest manner, specifying the nozzle height over the bed, as elsewhere.

In a few days I'll be able to check it out. But right now, I think there is a 50%-50% chance I found a compiler bug in the floating point math. (I had a Phd TA (Teaching Assistant) my first year of engineering that was a Computer Science Major. He cautioned us about ever screaming "Compiler bug!" ) It is going to take me a couple of days to prove (or disprove) it. But right now... I've got enough hard data that I'm very suspicious.

It could just be a rounding error. But I'm seeing the flaw at 4 decimal digits of precision. So with 4 byte floats, I'm having a hard time explaining it. If it is just a rounding error, the recursive mesh_buffer_line() routine has to be re-written. That is where the error is showing up.

[boelle]

Any news here?

[thinkyhead]

"Ladies and gentlemen, @Slavulj has left the building."

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