Z_offset does not change the Z=0 position

[LVD-AC]

I calibrated my delta printer which has a probe that is activated by pressing down the nozzle and when I send a G1 Z0 command the effector goes down just to spot where the nozzle presses into the bed and activates the probe switch. So far so good. Then I issued a M851 Z0.3 to set a z_offset so the printer would lay it's 1st layer a little bit above the bed, but no matter what I set the z_offset to, the printer always goes to the same position with G1 Z0 even after G28 and tries to print on the same z_height scraping the bed, even if I give z_offset ridiculous values like -10 or 10. Isn't G851 supposed to change this?

I have no bed levelling enabled at all. This is since the latest commit #8458 in bugfix-1.1.x as well since #8456 in bugfix-2.0.x.

What need I to do to get the nozzle right for the 1st layer?

[LVD-AC]

A patch is needed to G33 to keep the print height of the first layer in sync with the changes to zprobe_zoffset by issuing command G33 P0 after each zprobe_zoffset change. That fixed it.

see #8489 and #8490;

[brantuck84]

I compiled the latest bugfix build for a folgertech ft5 and am having a similar issue with my offset. I use a bltouch and no matter what I have my offset set to after the very first line goes down the nozzle drops down onto the bed.

[LVD-AC]

new patches for this problem: #8505 and #8506 (does exactly the same thing but a little different)

[LVD-AC]

@brantuck84:

The Z=0 reported by G30 probing and Z=0 used by G1 to move the print-head are deliberately kept out of sync perpetually. Give the latest patches above a try and issue an G33 P0 command after each M851 to re-synchronize the G1 Z=0 again with the G30 Z=0.

[thinkyhead]

Then I issued a M851 Z0.3 to set a z_offset so the printer would lay it's 1st layer a little bit above the bed, but no matter what I set the z_offset to, the printer always goes to the same position with G1 Z0 even after G28 and tries to print on the same z_height scraping the bed

That's not how M851 works. After you change it, you must re-probe to use the new value. It's not a live Z offset. It's never been a live Z offset. It will never be a live Z offset.

To set a new current Z position, you can use G92. Or, you can adjust live with BABYSTEPPING which now has the G-code M290. There was also a home_offset which used to apply to Delta and cartesian, so you could use M206 Z to adjust the home offset. That feature was seldom used, so it was hijacked for use as a delta height offset. It sounds like it may be useful for Delta in some circumstances after all.

After adjusting the Z height at the start of a print, take a note of the needed adjustment, apply it to your Z probe offset with M851 Z and save it with M500 for your next G29 / G26 / G33 probe operations.

A patch is needed to G33 to keep the print height of the first layer in sync with the changes to zprobe_zoffset by issuing command G33 P0 after each zprobe_zoffset change. That fixed it.

Documentation is needed to explain how M851 works, and to get users to stop expecting retroactive adjustments of previous settings.

Running G33 in response to M851 is hackish at best, and breaks the narrow scope of M851. PRs that do this by cannot be accepted. It's no different than having M851 start up a G29.

[LVD-AC]

That's not how M851 works. After you change it, you must re-probe

So basically you say M851 needs to be followed by G33; this is exactly what I say as well: change z_offset with M851 and if you want this to reflect in printed height as well run G33 again. A correction in the code(*) is needed for G33 P0 to work; it is confusing that G33 P1 and larger works but G33 P0 doesn't.

Running G33 in response to M851 is hackish at best... PRs that do this by cannot be accepted

Have it one way or the other either you must re-probe or you're not. The difference is G33 is not automatically run when M851 is invoked. The user can choose. But preventing the user from running G33 (= re-probing) after M851 by insisting on having a non-functional G33 is beyond my comprehension.

"since users who do not want to recalibrate will be confused by an auto-calibration routine that does calibrate things"

DOH, if you do not want to calibrate or recalibrate, do not run G33 auto-calibration, and if you do not want to change your probe z_height do not run M851, how confusing can this be!!! But users who want to recalibrate their printer after a M851 and choose to invoke a G33 for that purpose expect G33 to do its job.

M92 and M290 are reset when the printer is homed, so unsuitable for the task at hand. And M206 is disabled for deltas since the X and Y components force the centre out of the way of the real centre and this is like applying tower_radius_adjustments that set off the calibration as well as the printed dimensions. M206 could do the trick if XY are disabled for deltas, and only Z is used. But at the moment XYZ are all disabled.

Some of the attempted mesh adjustments, and so on, can be facilitated by changing the stored mesh Z values in terms of the nozzle position (#8493)

(*) But G33 that stores one single Z values in terms of the nozzle position (I've called it doing a raw calibration) in order to overcome the problem is

hackish at best ... PRs that do this by cannot be accepted

I'm giving up, you make no sense at all @thinkyhead

That's not how M851 works. After you change it, you must re-calibrate the delta_height

but you're not allowed to use the auto-calibration routine to do that, because a calibration routine that calibrates things is confusing to people who do not want to recalibrate things.

G28 is as confusing to people who do not want to home the printer and G1 is confusing to people who do not want to move the print-head.

(sight)

[thinkyhead]

I'm giving up, you make no sense at all @thinkyhead

Did I misunderstand? Sorry! Somehow I got the idea that G33 would be invoked automatically by M851. Apparently not……

But preventing the user from running G33 (= re-probing) after M851 by insisting on having a non-functional G33 is beyond my comprehension.

I'm not insisting on having "a non-functional G33." I have to object to a methodology where G33 has a saved state related to zprobe_zoffset, requiring it to keep a copy of zprobe_zoffset and transparently apply adjustment based on interim changes to zprobe_zoffset.

G33 should not care about zprobe_zoffset outside the scope of a single probe. That offset is for the probe-of-the-moment to use and forget, and then for almost everything else to know nothing about.

---

Background: Right now for the sake of stability we're reverting some recent additions and taking zprobe_zoffset back to Simpletown, where nothing outside of a single probe knows about zprobe_zoffset. The concept of an adjustment to zprobe_zoffset rewriting all mesh data that was based on that offset is not a bad one, per se. But the codebase isn't ready for it, the concept does sacrifice some optimizations, and until all previous probe operations can be re-adjusted, we are taking a step back.

[LVD-AC]

For the sake of stability something needs to be done with G33 to cater for these changes. As I said before delta users also need to be able to set the print height of the 1st layer. M206 and all functionality related to home and workspace offset are disabled on delta's; they are disabled for a good reason: they do not function properly on delta's; only the Z can be used without causing a lot of trouble.

So how about this:

• for people who calibrate manually (either by probing certain points or doing papertests) and are configuring the delta parameters manually, it is of their choice to set the delta height manually as well to tune the print height of the 1st layer.

• for G33 users: have probe_point report without z_probe_zoffset to G33 probes (there's 2 modes now set by bedlevelprobe) AND let G33 have its own G33_z_offset, modifiable with G33 Zx.xx - nothing to do with M851 and zprobe_zoffset - but that calibrates the delta parameters (including delta_height) at a certain distance from the trigger level.

For the time being, until G29 and M851 have found a stable solution for the z_offset problem. And if that solution is suitable for G33 as well; G33 can be modified at that point to take use of that and abandon its own G33_z_offset. And if the final solution is unsuitable for G33 without applying smart tricks, G33 just keeps its own G33_z_offset.

[thinkyhead]

how about this

I think that's all fine. In general whatever makes it nicest from user perspective, but doesn't introduce things we'll have to disentangle later. At the moment I see a lot of "leveling works, I'm happy!" reports on closed issues, so if we're cautious, we might have a pretty stable 1.1.9 release!

a stable solution for the z_offset problem

I assume "the z_offset problem" refers to the Z-offset-change-retroactively-applying-to-previous-measurements problem… Which wasn't really a problem until such an idea was proposed!

I keep thinking about the moody inductive probe example. No matter how you think the new offset found today will apply again tomorrow, it turns out that it's going to be off again tomorrow because Mars is aligned with Venus. At that point, there's just nothing to be done about it. The bed mesh will have its contours correct, but babystepping is an unavoidable need.

With a hard switch probe and a moving Z endstop, I'm more amenable to the babystepping change being preserved for the next print. But in general we know that inductive probes are a moving target, and only rigid machines with well-fixed endstops even have reliable Z homing.

So actually, one of the G-codes I want to add just activates the Z babystepping screen on the LCD. I'm sure it will be very popular addition at the front of many prints!

[PrintEngineering]

I see this issue is currently closed, so I apologize if I didn't fully understand the entire conversation, but I have not found my resolution here.

My problem is simple. I am writing a z offset script for some TFT firmware, and I just wanted to go below z=0 for manual adjustment.

I begin by sending and adjustment through M851. Then I try running a G92 (as mentioned as a solution by Thinkyhead above) to adjust the position after the M851. The assumption is that this readjusts the software endstop, which will no longer be constrained by the old M851 values. However, this behavior is not observed.

What I have gathered from the conversation above is that we are expected to reprobe after changing M851. But that is not reasonable when we are in the process of adjusting by a series of small incremental moves. Imagine reprobing after every 0.12mm of movement as you fine tune the offset. That would be pretty frustrating.

Upon reading the documentation for G92, I see that it used to ignore software endstops. I really wish it would have stayed that way. Since it does not, might we at least be able to get the software endstops IMMEDIATELY adjusted by M851? Ultimately a parameter of M851 that would automatically readjust software endstops would be ideal. That is, after all the whole point of setting the z offset to begin with.

I have tried M211 to circumvent the issue, but the problem with that is twofold. Now I have to go into my parser and manually mute the echoes for M211, and the twofold (toggled) usage is messy to implement and a small error could allow the call to M211 S1 to be missed when finished with M211 S0 state. Now, every time I implement a negative movement from the z offset menu I have to stack multiple Gcode commands, starting with M851, then M211 S0, then G1 Z0.2, then M211 S1. All wrapped in a series of G90/G91 layers. THEN I have to run a G92 in the hopes that it saves the correct position for my users to manually level the bed in the next menu. The menu immediately preceding z offset is a z probing. So if setting the z offset then requires reprobing to implement, there should be a fix. The whole process is very messy.

It would also be much better to have a parameter on G1 that activated the M211 S0 state, such as an "I" parameter as is used for M43 when you want to ignore the restrictions of protected pins.

Or is there a Gcode for manually adjusting software endstops?

It would also be helpful if the documentation was more clear on what actually occurs in the event of M851. It makes no mention of its impact on the software endstops.

[PrintEngineering]

Just to clarify what behavior is actually observed:

M211 S0 G1 Z-1 ;moves to -1 G92 Z0 ;terminal ack ok G1 Z0 ; terminal ack OK, no movement. G1 Z1 ;terminal ack OK, no movement G1 Z5 ;terminal ack OK, no movement G92 ; states Z position is 5. However, after sending G92 Z0, NOTHING will move and no errors were generated. Position values within Marlin are updated, but steppers do not activate.

I am running 2.0.5.3

[PrintEngineering]

Upon further examination, I believe that I have identified the problem.

When a G92 is sent, it changes the stored position but not the count. Software endstops are set by the count, not position. G92, therefore, fractures the steps and counts into two separate entities. I cannot imagine why that would be a good thing or why we would be restricted from setting our own values. The software endstops should always be relative to positions, so if counts are offset by G92, it is a bug that they not be corrected to match the new position, or at least have a parameter to do so.

It is also most certainly a bug that the steppers lock up when a G92 is set past the software endstops. This behavior is unwarranted, and easily recitified by resetting the count OR passing an automatic G1 to the endstop in lieu of locking up the whole machine.

I get the feeling we are being coddled and treated like we aren't responsible enough to control our own machines, and it is restricting the overwhelming majority of us that are adult enough to take responsibility for our own machines from working efficiently.

[lrpirlet]

@G2Barbour or maybe this is intended behavior… see G92 NOTES: https://marlinfw.org/docs/gcode/G092.html

[PrintEngineering]

@G2Barbour or maybe this is intended behavior… see G92 NOTES: https://marlinfw.org/docs/gcode/G092.html

I had seen that G92 respects software endstops. But locking the machine can't be the intended behavior. It should at least move in the direction of the endstop (towards positive) when negative.

Also, there should be some way to accomplish a live z offset adjustment without having to reprobe. G92 seems like a logical place to put it. Either a parameter on G92, or a parameter on M851 to reset steps by the change in offset. The fact that there is no solution whatsoever is a bug, imo. It is like we are being told we are not allowed to interact with our machines in the most intimate and productive way because of the risk that a few of the less responsible could crash into the bed. Well, I've got news on that topic: there's much easier ways to crash into the bed, we've all done it! By the time we are sending G92 or M851 with a special override parameter to ignore software endstops, we have thought it through far more than the times we accidentally crash the nozzle. And by allowing a solid and efficient way to set z offset, the likelihood of crashing the nozzle actually goes down! All I'm trying to do is make a reliable piece of software to set the z offset so that users can operate the printer as smoothly and safely as possible. Having to force them to set the z offset blind, or run a second probe after finding the offset number is a deterrent to safe operation. It basically negates the value of having the gcode commands to begin with.

[LVD-AC]

This issue has absolutely nothing to do with software endstops but by removing this line of code: `` delta_height -= diff; This was after a lenghty discussion fixed by redefining the delta_height parameter and adding the missing line to the homing procedure, so the issue is closed.

Possibly #8456 caused other problems as well, but this should be reported in a different issue, very little people read old issues that are closed.

[github-actions[bot]]

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.