Setting Z_RAISE_AFTER_PROBING to 0 ignores G92 after G29

[radry]

When setting Z_RAISE_AFTER_PROBING to 0 any G92 command after completing G29 is ignored.

What I'm trying to do: After G29, my start script will set "G92 Z0.35" to set the correct nozzle height.
So to make this work I now (1.1.0 - RC6) have to set Z_RAISE_AFTER_PROBING to a positive value and then run G0 Z0 to get back down. Only then it accepts G92.

Probe is fixed.
Z_PROBE_OFFSET_FROM_EXTRUDER is set to 0. (No, I don't want to adjust the gap via this variable.)

It worked fine in 1.1.0-RC3 because in that version Z_RAISE_AFTER_PROBING was ignored for some reason.

[thinkyhead]

Z_PROBE_OFFSET_FROM_EXTRUDER is set to 0. (No, I don't want to adjust the gap via this variable.)

But that's what this setting is for.

Are you saying that your G92 Z0.35 command is having no effect? It should at the very least set the current Z coordinate to 0.35.

Your anomalous behavior is probably because you're abusing G92. You can't move any lower than the physical limit (Z_MIN_POS) you have set, and G92 cannot be used to get past the configured limits. This is because G92 actually updates the software endstops so they remain at the same relative position. In other words, if your Z-min software endstop is set to 0 and you use G92 Z5 your Z-min software endstop will now be 5, so you still cannot move any lower.

You can get around the limit by setting min_software_endstops to false.

Why don't you want to set Z_PROBE_OFFSET_FROM_EXTRUDER to -0.35?
If you did, Marlin would just "do the right thing."

[radry]

G92 Z0.35 has no effect. The Z cordinate doesn't get updated to the new value and remains at 0. Thus I can't go any lower obviously because of the software endstop limit. If Z_RAISE_AFTER_PROBING is above 0, the Z cooridnate gets updated to the specified value.

G92 should set the current Z position to the specified value. It was always like that. So if I set G92 Z0.35 the FW should set the current Z position as 0.35 (but not move the axis) and thus I can move 0.35mm lower up to the "new" 0. (Which is -0.35 in the pre-G92 config). I hope that makes sense.

I think this should be marked as a bug. Since it works when Z_RAISE_AFTER_PROBING is above 0.

Why don't you want to set Z_PROBE_OFFSET_FROM_EXTRUDER to -0.35?
If you did, Marlin would just "do the right thing."

If I change the extruder/nozzle the offset changes. Also different hotend temperatures result in a different offset (because of the heat induced extension of the nozzle). I would have to reflash the FW every time. It's much easier to adjust the start script in the slicer software to the right value with G92. I like it this way. It's fast and efficient for me.

[Blue-Marlin]

@radry
What is more efficient in G92 than in M851?

[radry]

The issue is not about how I do things. It's about a bug. A setting that causes a command not working for an unknown reason.
Maybe issuing G0 Z0 after G29 will make G92 work afterwards, even if Z_RAISE_AFTER_PROBING is 0. I'll have to try it.

[DjDemonD]

There was a method of determining z offset by sending g92 z10 after homing z. This was to circumvent the travel limits to allow offset measurement using the paper method. However I tried this using bugfix the other day and as thinkyhead points out it won't go below the travel limits even after a g92 z10 with the nozzle just above the bed.

However you can temporarily disable software endstops or set them to allow a couple of mm below z=0. Or use babystepping while printing a test object which now reports the change in z height in mm. Before the next print use m851 to create a z offset, m500 to save. Perhaps we ought to ask Thomas Sanladerer on his youtube channel to update his video on implementing ABL as a lot of people use this guide where the g92 z10 method is advised.

[radry]

So the problem is that G92 can't overwrite the software endstop limit. That means G92 is broken, since the sole purpose of G92 is to set absolute zero.

[DjDemonD]

I'll not answer this directly as I am sure one of the Marlin dev's will have the correct answer but I presume G92 does not allow travel outside the travel limits for a good reason, which might not be immediately apparent. There is another method (above) if what you are doing is determining z offset.

[thinkyhead]

Looking at the code for G92 I can see no reason why it would not update the current position. In fact, it always updates current_position.

Please tell me you are testing against RCBugFix because otherwise we are not on the same page.

[AnHardt]

@DjDemonD
Making the software endstops selectively switchable by g-code is still on my todo-list.
The probe cleanup project grow and grow but will be finalized soon (I hope).

Well - let's look at the name - END STOP.
The more interesting question is - where is the end. It should clearly not be below the bed. And if the place called zero is below the bed you can't reach zero.

So - where is the bed? At the moment the probe triggers the bed is Z_PROBE_OFFSET_FROM_EXTRUDER mm away from the nozzle - that is the definition for Z_PROBE_OFFSET_FROM_EXTRUDER.
'physical NULL' is now Z_PROBE_OFFSET_FROM_EXTRUDER mm below the nozzle - the software endstop is adjusted to this (homing).
Now we can add different offsets to adjust the number for that point.
These offsets are also applied to the number we stored for the software endstop. So the endstop should always trigger at 'physical NULL'.
Consequence is - if your Z_PROBE_OFFSET_FROM_EXTRUDER is set to 0, you cant go below the probes trigger point.
For adjusting the Z_PROBE_OFFSET_FROM_EXTRUDER this means - begin with a too small number (usually the number is negative). For example -10 if you expect -5 to be about correct. Now do the paper test. Be careful - you can go below the bed now. Then correct the value by the number in the display (if the other offsets are zero). If you read +6 the correct value is -10 + 6 = 4.

(At least - that's the (my) plan)

[radry]

Thank you for your explanation. My question is still: What's the purpose of G92 in this case? G92 is supposed to set "physical NULL", as you call it. So why can't it overwrite what the auto bed level determined?

[thinkyhead]

Whatever the "purpose" of G92 is, its effect is to redefine what the current position of the nozzle is.

So, for example, let's say you have typical software endstops, where you can't go below zero in X, Y, or Z. Now, let's say you move your carriage with G1 X100 and then issue G92 X0. What do you expect to happen if you then issue G1 X-100? Do you expect the carriage to move left or to be limited?

If we didn't change the X software endstop to -100 in response to the G92 X0 command you would be unable to move left. Earlier versions of Marlin behaved this way, leaving the software endstops unaltered. Feedback from the CNC community convinced us that this was a bug, so we have fixed it.

We could certainly extend G92 to take an additional argument, such as S1 to leave the software endstops unaffected. But that should not be the default behavior.

[radry]

Now, let's say you move your carriage with G1 X100 and then issue G92 X0. What do you expect to happen if you then issue G1 X-100? Do you expect the carriage to move left or to be limited?

Of course it shouldn't move left after that command. Why? Because the software endstop is X=0 and the carriage after G92 X0 is at X0. If the endstop is not updated you could move to X=-100, which doesn't make sense, since the endstop is explicitly set to 0.
So if I move the nozzle G1 Z1 then issue G92 Z2, it MUST be able to travel -2 on Z to the new 0.

[thinkyhead]

@radry Sorry, but that is no longer the behavior of G92 in Marlin. We keep the software endstops in the same physical positions, no matter what you do with G92.

Otherwise (in the above situation) you would also be allowed to move to X=200, past the physical limits of the machine, grinding the stepper motor, which is what the software endstops are there to prevent.

The way you're trying to use G92 is simply not supported. If you want to be able to move below the bed, you should set your Z_MIN_POS to -2 and then set your Z_HOME_POS separately to 0 (with MANUAL_HOME_POSITIONS). When you home, your Z will then be 0, but you will still be allowed to move down by 2mm, because you have set the hard limit lower.

[jstefanop]

Whats the difference between M206 and M851? Since we shouldn't use G92 for Z probe offset tweaking whats the better option?

[thinkyhead]

M851 sets the Z distance between the nozzle and probe. (i.e., the negative of the position of the nozzle when the probe is triggered). This is the one and only supported option to get your machine to properly assign the correct Z position when you probe the bed.

M206 sets elements in the home_offset array and updates the current position based on the difference from the old home_offset values. After using M206 and homing with G28, the current coordinates will be your configured home (min or max) modified by values given in M206. Thus if you normally home XY to { 0, 0 } then after M206 X10 Y4 your next G28 will set the XY coordinates to { 10, 4 }. If your nozzle was at { 100, 100 } it will now be at { 110, 104 ). M206 has nothing to do with probing, per se. It merely sets the origin of the coordinate system.

Both G92 and M206 modify the software endstops to keep them in the same relative positions.

[jstefanop]

Yea I think the confusion with these commands is mostly around ABL and how many printers use an IR probe for both ABL and the Z endstop. Since these IR probes are finicky we can't rely on just Z_PROBE_OFFSET_FROM_EXTRUDER to be set in firmware and forgotten. This offset needs to be changed all the time between different bed treatments, layer heights, lighting, etc.

Up until RC3 G92 Z1.1; was the go-to way to do this after homing and ABL. Since my IR probe currently triggers when my extruder nozzle is 1.1mm above the bed.

Going forward it looks like both M852 Z-1.1; and M206 Z1.1; should do the same thing?

[thinkyhead]

Going forward it looks like both M852 Z-1.1; and M206 Z1.1; should do the same thing?

M851 and M206? No, they don't do the same thing.

M851 Z-1.1 sets zprobe_zoffset to -1.1. Z probing will then use this offset value.
M206 Z1.1 sets home_offset[Z_AXIS] to 1.1 (and modifies current_position[Z_AXIS], sw_endstop_min[Z_AXIS], and sw_endstop_max[Z_AXIS]).

[jstefanop]

Ok but its two different ways of doing the same thing no? The IR prob triggers 1.1mm before the hottend tip reaches the bed surfaces, so the "trigger" in traditional sense is -1.1mm offset from hotend tip.

Setting M851 Z-1.1 tells the firmware this exact thing, so after homing G0 Z0 should bring the nozzle to touching the bed.

Im assuming the same thing can be achieved by sending M206 Z1.1 AFTER homing, setting the Z coordinate system offset by 1.1mm so it knows when the Z prob triggered it actually trigger 1.1mm above the bed and not at Z0.

Am I understanding this incorrectly?

[thinkyhead]

Am I understanding this incorrectly?

I think so!

If you use M206 Z1.1 now the bed is not at Z=0 anymore. The bed is now at Z=1.1. Assuming you have min software endstops enabled, you can no longer move the nozzle to Z=0 (which is now 1.1mm below the bed). The minimum Z coordinate where you can move it will now be 1.1.

When you start to print, the GCode will tell your machine to move to Z=0.2 (perhaps) to start the first layer. That will try to put the nozzle 0.9mm below the bed (1.1mm lower than you probably want). But the Z min endstop will not let it go that low, so the nozzle remains on the bed (at Z=1.1). In fact, the nozzle will not raise at all until the GCode tells the machine to go above 1.1mm. If printing with 0.2mm layers, the machine will print 6 very squished layers before it starts to raise the Z axis. Your hotend will be very jammed.

Et cetera, et cetera… because M206 changes the coordinate system.

[jbrazio]

Closing due to inactivity.
Please re-open this issue if still valid.

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