Marlin: Z Probe_Offset not seeming to work in RC7

[timeshell]

Ever since upgrading to RC7, the Z axis doesn't seem to compensate using the probe_offset anymore. Using the new BLTouch definition. I haven't tried to configure without it yet. Any known reason why this would be happening?

[Roxy-3D]

This has been seen by a number of people and in different configurations. The problem is real.

You should try the latest RCBugFix and see if it resolves your problem. There have been some changes made that might fix this issue.

If it doesn't fix your problem... Here are some more thoughts:

If you have an LCD Panel and enable Z-Baby-Stepping, the Z-Offset can be adjusted. So the bulk of the Z-Offset logic is correct. However, there is some place where it is wrong and causing trouble.

You can side step the problem by not using the Z-Offset (except for Z-Baby-Stepping). Set the Z-Offset to 0.0 and then exactly calibrate your Z_OFFSET_FROM_EXTRUDER number in Configuration.h. It might take 3 or 4 iterations to get it exactly correct. But at that point you shouldn't have a problem.

[thinkyhead]

This issue duplicates #4577, #4220, #4520

I've just merged some changes that may produce a better result. So download RCBugFix and try it at your first opportunity. Be sure to enable DEBUG_LEVELING_FEATURE and use M111 S255 to enable full logging before testing. If you encounter problems, post the log output here so we can see what's going on.

[timeshell]

Still not working.
RC-Z-Homing-Offset-Issue.txt

I'll also add that the Z offset on the LCD display was showing the offset as -0.75mm. However, my code was trying to set it to -0.45mm. That seems a little wrong...

Anything to do with this line in Marlin_Main.cpp?

              z_raise = 0.3 + (z_diff > 0.0 ? z_diff : 0.0);

Possibly yes. I took the 0.3 out of the above line and it showed the offset amount in Configuration.h correctly. Removing the 0.3 seems it may solve the Z homing issue.

HOWEVER, the g29 does not work at all in the RCBugFix I downloaded. It sits in the front left corner for every probe point. SO, I can't test the Z probing during g29 yet. And I forgot to get the log for that so I'll have to get it later.

[thinkyhead]

Anything to do with this line in Marlin_Main.cpp?

No. Not unless you're on the cutting edge:

#if ENABLED(SWITCHING_EXTRUDER)
  . . .

Removing the 0.3 seems it may solve the Z homing issue.

It's the placebo effect. Unless you're using SWITCHING_EXTRUDER.

[thinkyhead]

@timeshell What do you mean by "compensating"? Your G28 log looks fine to me. Your probe offset is -0.75 and when it homes with the probe, your Z is set to 0.75.

[timeshell]

G28 was fine. I was in error about that. The g29 didn't work. And I wasn't able to test the original problem as a result.

I set the offset in the configuration.h to -0.45. But as after uploading it, the LCD showed the Z offset was -0.75. I had to removed that 0.3 and then if showed on the LCD as I had set it. But the Z offset still didn't work properly when about to print when I removed it on RC7, so yes that wasnt the original problem.

I'll test it again in a couple days. Maybe something else happened when I was testing that affected the result.

[timeshell]

I had also edited my post before you responded. I realised I was wrong. It doesn't say that anymore.

[thinkyhead]

@timeshell We have several duplicates of this question concerning the Z position after G29, and are already trying to isolate the issue and provide an intelligent solution. First test the current RCBugFix to determine the extent of the issue. You may want to disable EEPROM to avoid confusion about what your actual probe offset is. After you've tried RCBugFix please test this branch — https://github.com/thinkyhead/Marlin/tree/rc_final_z_correction — which proposes one possible solution.

[timeshell]

Thank you. I'll advise of my results on Tuesday.

[rogueqd]

I just installed an IR z-probe yesterday and encountered an issue similar to this.
Chaging the Z_OFFSET_FROM_EXTRUDER had no effect, but changing the z-offset via the LCD had the desired effect.

I'll also try the z_correction update when I can, but it will probably be a couple of days.

[thinkyhead]

@rogueqd You don't just happen to have EEPROM_SETTINGS enabled, do you? If you do, you need to use M502 to reset the current settings to the defaults, or, after you change the offset using the LCD or M851, you must save it to EEPROM using M500. If you don't do one of these, you will simply get the last value that was stored in EEPROM. Capisce?

[rogueqd]

I've changed the z-offset in EEPROM to 0.0 and saved it, just to remove it from any future testing.
I just tried the rc_final_z_correction firmware, it got some of the way through the G29 and the steppers started skipping. It was working fine only a few minutes before with older firmware (rc_bug_fix from a week or two ago). I tested twice, the skipping was different in each test but neither G29 completed successfully.
Edit: I tried the latest rc_bug_fix and got the same skipping issue.

[Roxy-3D]

Nothing has changed in the stepping motor code for a while now???

[thinkyhead]

Which of your steppers is skipping? All of them, or just the Z?

I suggest doing a full reset of settings with M502 and M500 and testing again. If the problem persists, then we should look at your acceleration values.

[rogueqd]

It's a delta. I didn't really pay attention to which individual motors, but the head seemed to lose is position along the X axis (not X tower). That's ok. It's not really relevant to this bug, just prevents me from testing at the moment. The acceleration values haven't changed, I just copied over the same config file I've used for all my 1.10 testing, except I had to update the name of the prevent_cold_extrusion define.

[thinkyhead]

seemed to lose its position along the X axis

Hmm. That can't just be related to a single stepper (unless you have one exectly parallel to the X axis) so you're implying a fundamental flaw in the tracking of position.

[Frostyybeer]

@thinkyhead I am having a similar issue where my z_probe_offset would not compensate after sending a G28 command. I tried both the RCBugFix and the rc_final_z_correction branches without any success. If you could please take a look at my log.txt and my firmware setup (Marlin-RC7_BugFix.zip) that would be much appreciated.

Thank you in advance for your time.

• Nate

[rogueqd]

Ok, so I found a mechanical fault with my printer this morning. Please disregard my earlier comments about skipping.

[cruzpablo]

I have same problem. Any solution ? After write marlin-rc firmware working fine 5 days, and return this problem

[thinkyhead]

@Frostyybeer @cruzpablo Is your probe connected to the same pin as your z min endstop? If so, you should use Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN instead of Z_MIN_PROBE_ENDSTOP, because with the latter option _Marlin assumes you are homing Z with your endstop, and not with your probe_. You can see this at line 1568 in Marlin_main.cpp:

    #if HAS_BED_PROBE && Z_HOME_DIR < 0 && DISABLED(Z_MIN_PROBE_ENDSTOP)

The Configuration.h file explains this side-effect:

// Enable Z_MIN_PROBE_ENDSTOP to use _both_ a Z Probe and a Z-min-endstop on the same machine.
// With this option the Z_MIN_PROBE_PIN will only be used for probing, never for homing.

[thinkyhead]

@AnHardt @Roxy-3D I'm not fond of this "side-effect," but at least it is documented.

[AnHardt]

@thinkyhead
You already know - i'm not a friend of the current naming. Having discussed this for over a year now, i have no further helpful contributions about that.

If we home with a z-min-endstop - that's not a probe - there is no probe-offset - that's logical.
The logical way out, are endstop offsets - also for Cartesian systems.

Q: Why is z-probe offstet different between G28 and G29?
A: Because it's designed that way.
Assuming you have a system, able to do bed-leveling, there is no reason not to use bed leveling.
Why not simply using the 'd' result? Because 'd' is the average level for the measured points. At that level we are scratching the highest parts of the bed. Using a z-probe offset, including the d-correction, we have to find by experiment is not more inconvenient, then if the d-correction would not be included.
(As far as i remember, that was state of the discussions a ~9-12 month ago when a PR about this was rejected (ether here or in Dev))

[Frostyybeer]

@thinkyhead I am using a separate z probe for probing (assigned it to pin 57 in pins_RAMPS.h) and a z-min endstop for homing. I test the signals with M119 and all endstops are working correctly as well as the inductive probe. Could it be that I have to define/undefine something else in order for my configuration to work properly? I am slowly losing my hair over this issue... Thank you for your reply.

As to why I am using separate z-probe and z-min endstop is because my nozzle park outside of my bed area where the inductive probe won't trigger when homing.

• Nate

[thinkyhead]

@Frostyybeer You wrote:

my z_probe_offset would not compensate after sending a G28 command.

If you're using your Z min endstop to home, then no offset should be applied with G28.

[Frostyybeer]

@thinkyhead So if my nozzle is too high above the print bed when print start (after bed-leveling with G29) what could be causing the problem?? I have tried adjusting the z-probe offset in the firmware but my nozzle still stay at the same height.

• Nate

[thinkyhead]

Your log.txt looks ok.

When you home with G28 it apparently sets the current position to 0,0,0 which is good. It means you haven't set an offset using M206. I assume that after G28 your nozzle is very close to the bed, yes?

From that point you should simply be able to print.

So, when you start a print, what is the first Z position that it goes to – for the first layer?

[Frostyybeer]

@thinkyhead The nozzle sit perfectly fine after G28. The issue is when I am printing something (at the start code I have G28 follow by G29 command) the nozzle is too far away from the print bed in the (+) direction.

I will go ahead and try adding M206 with the right compensation to see if that solve my issue or not. However, let say I have more that 10 printers, is there a way to set it permanently in the firmware without having to put M206 at the start of every print?

• Nate

[thinkyhead]

M206 is irrelevant to your issue. You shouldn't need it.

If you home with G28 and the position is set to 0,0,0, and your nozzle is touching the bed at that point, you should be all good. Unless there's something odd in your GCode.

Did you add any codes into your slicer's GCode Prefix that could be affecting behavior?

[Frostyybeer]

In simplify3D for the Starting script I only have G28; home all axis follow by G29; auto bed leveling. My first layer height is set to 130% of 0.3mm (= 0.39mm). The LCD screen seem to be showing the correct value of first layer z height when printing. However, the actual height is completely off by more than 2.0mm

• Nate

[thinkyhead]

So, what is the result if G29 is left off?

[Frostyybeer]

When printing without G29 the actual height seem to be very close to the 0.39mm.

• Nate

[thinkyhead]

Can you post a log of the G29 output with DEBUG_LEVELING_FEATURE enabled, and after M111 S255? I'd like to see whether your M851 offset is actually accurate, or if it could be off by ~2mm.

You may also want to check to see what height it's at when it gets triggered, to make sure it's set correctly. You can do a single probe with G30.

[Frostyybeer]

Debug Leveling Feature log output.txt

Output for G30
14:32:59.797 : current_position=(78.00, 59.00, 0.00) : setup_for_endstop_or_probe_move
14:32:59.797 : >>> probe_pt(43.00, 52.00, 1)
14:32:59.797 : current_position=(78.00, 59.00, 0.00) :
14:32:59.797 : do_probe_raise(5.00)
14:32:59.797 : >>> do_blocking_move_to(78.00, 59.00, 9.30)
14:33:00.442 : > do_blocking_move_to_xy(78.00, 59.00)
14:33:00.442 : >>> do_blocking_move_to(78.00, 59.00, 9.30)
14:33:00.442 : > current_position=(78.00, 59.00, 9.30) : set_probe_deployed
14:33:00.442 : deploy: 1
14:33:00.442 : do_probe_raise(15.00)
14:33:00.442 : >>> do_blocking_move_to(78.00, 59.00, 19.30)
14:33:01.130 : >>> do_blocking_move_to(78.00, 59.00, 19.30)
14:33:01.130 : >>> do_blocking_move_to(78.00, 59.00, -210.00)
14:33:04.008 : current_position=(78.00, 59.00, 0.16) : sync_plan_position
14:33:04.008 : >>> do_blocking_move_to(78.00, 59.00, 2.16)
14:33:04.336 : >>> do_blocking_move_to(78.00, 59.00, -1.84)
14:33:04.929 : current_position=(78.00, 59.00, 0.23) : sync_plan_position
14:33:04.929 : current_position=(78.00, 59.00, 0.23) : run_z_probe
14:33:04.929 : > current_position=(78.00, 59.00, 0.23) : set_probe_deployed
14:33:04.929 : deploy: 0
14:33:04.929 : do_probe_raise(15.00)
14:33:04.929 : >>> do_blocking_move_to(78.00, 59.00, 19.30)
14:33:06.220 : >>> do_blocking_move_to(78.00, 59.00, 19.30)
14:33:06.235 : <<< probe_pt
14:33:06.235 : Bed X: 43.00 Y: 52.00 Z: 0.23
14:33:06.235 : current_position=(78.00, 59.00, 19.30) : clean_up_after_endstop_or_probe_move
14:33:06.235 : X:78.00 Y:59.00 Z:19.30 E:0.00 Count A: 6552 Y:10126 C:1118

• Nate

[Roxy-3D]

Why not simply using the 'd' result? Because 'd' is the average level for the measured points.

There is one issue with just using d. Remember... The plane that was just calculated and described by ax+by+cz=d is offset from the nozzle. The Probe is offset by X_OFFSET_FROM_EXTRUDER and Y_OFFSET_FROM_EXTRUDER. If the plane is perfectly level, it won't matter. But with any tilt at all, as those two numbers get bigger, they start factoring in an extra Z correction number. The reason is we care about the nozzle's height, and not the probe.

At that level we are scratching the highest parts of the bed. Using a z-probe offset, including the d-correction, we have to find by experiment is not more inconvenient, then if the d-correction would not be included.

With the ABL correction turned on, if we are scratching the highest parts of the bed I think you can conclude that the bed is warped by more than the first layer height. Right?

[AnHardt]

There is one issue with just using d. Remember... The plane that was just calculated and described by ax+by+cz=d is offset from the nozzle. The Probe is offset by X_OFFSET_FROM_EXTRUDER and Y_OFFSET_FROM_EXTRUDER. If the plane is perfectly level, it won't matter. But with any tilt at all, as those two numbers get bigger, they start factoring in an extra Z correction number. The reason is we care about the nozzle's height, and not the probe.

Complete crap! See: https://github.com/MarlinFirmware/Marlin/pull/4670#issuecomment-242889972

With the ABL correction turned on, if we are scratching the highest parts of the bed I think you can conclude that the bed is warped by more than the first layer height. Right?

Yes. If it would still scratch a 'first layer height' the bed would be really bad warped. But that was not my point. My point was, if we only add 'd', half of the bed will be scratched at zero level - so 'd' is not the right correction because it's to deep.

[Roxy-3D]

There is one issue with just using d. Remember... The plane that was just calculated and described by ax+by+cz=d is offset from the nozzle. The Probe is offset by X_OFFSET_FROM_EXTRUDER and Y_OFFSET_FROM_EXTRUDER. If the plane is perfectly level, it won't matter. But with any tilt at all, as those two numbers get bigger, they start factoring in an extra Z correction number. The reason is we care about the nozzle's height, and not the probe.

Complete crap! See: #4670 (comment)

Wow! I think I'll just stay out of any discussion where you are 'contributing'.

@thinkyhead For sure... the nozzle's offset from the probe plays into the correction.

[AnHardt]

@Roxy-3D
I would not be so harsh if i hadn't wrote the paragraph about x/y-offsets in https://github.com/MarlinFirmware/Marlin/pull/4670#issuecomment-242889972 extra for you.

[Roxy-3D]

I read that twice. Even if you are correct, people that are trying hard to understand a difficult topic deserve some patience.

If I remember correctly, the original ABL probing did not compensate for the Nozzle's offset. In the original ABL, it was very important to add in a small amount of correction for how much the plane shifted its Z Position moving from the probe to nozzle. It maybe that because the probed positions are now 'corrected' to operate in the Nozzle's coordinate system that doesn't need to be done. That kind of an answer is actually helpful and would have been appreciated.

[thinkyhead]

We all are surely a little Aspergers. Some a bit more than others.

[thinkyhead]

@Frostyybeer Am I correct that your Z_PROBE_OFFSET_FROM_EXTRUDER (aka M851) is set to -4.3 ?

If you've been testing with RCBugFix (and I hope you have) then please re-download and try again. I accidentally left in a redundant adjustment in the homing of Z when homing with a probe. It probably isn't related, but it never hurts to have the latest code.

And then, please test one or both of my branches, which are attempting to come up with solutions.

This one adjusts Z based on the homing position:
https://github.com/thinkyhead/Marlin/tree/rc_fix_leveling_maths

And this one adjusts Z based on the final probe position:
https://github.com/thinkyhead/Marlin/tree/rc_final_z_correction

[Frostyybeer]

@thinkyhead

Correct, I set the Z_PROBE_OFFSET_FROM_EXTRUDER in the original RCBugFix firmware to -4.3mm just to see if that would do anything to adjust my nozzle height after ABL. (It does not)

When trying the rc_fix_leveling_maths after ABL my nozzle is crashing to my print bed (differ than previous issue where the nozzle is too far above the print bed). However, when trying to adjust the Z_PROBE_OFFSET_FROM_EXTRUDER the same problem occur where my nozzle still crash to the print bed regardless of whatever number I put.

As for the rc_final_z_correction, I got this error when flashing firmware.
Error.txt
As @Blue-Marlin mentioned below, please disregard the previous statement, I input the incorrect value for my X_PROBE_OFFSET_FROM_EXTRUDER (should be -35 instead of -3.5)

• Nate

[Blue-Marlin]

// Z Probe to nozzle (X,Y) offset, relative to (0, 0).
// X and Y offsets must be integers. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
// In the following example the X and Y offsets are both positive:
// #define X_PROBE_OFFSET_FROM_EXTRUDER 10
// #define Y_PROBE_OFFSET_FROM_EXTRUDER 10
//
//    +-- BACK ---+
//    |           |
//  L |    (+) P  | R <-- probe (20,20)
//  E |           | I
//  F | (-) N (+) | G <-- nozzle (10,10)
//  T |           | H
//    |    (-)    | T
//    |           |
//    O-- FRONT --+
//  (0,0)
#define X_PROBE_OFFSET_FROM_EXTRUDER 0  // X offset: -left  +right  [of the nozzle]
#define Y_PROBE_OFFSET_FROM_EXTRUDER 50  // Y offset: -front +behind [the nozzle]
#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.21   // Z offset: -below +above  [the nozzle]

[Frostyybeer]

@Blue-Marlin I should have read that "// X and Y offsets must be integers."
Thank you.

• Nate

[Frostyybeer]

@thinkyhead

The rc_final_z_correction branch _solved_ my problem perfectly. The ABL-(Auto Bed Leveling) is now working like it supposed to.

I can adjust the Z_PORBE_OFFSET_FROM_EXTRUDER in the firmware and my nozzle will react according to the value I input. For example, by decreasing the value from -1.0mm to -2.0mm the printer will put my nozzle closer to my print bed by 1.0mm after G29 and vice versa.

Cheers!

• Nate

[thinkyhead]

@Frostyybeer I'm gratified to hear that the rc_final_z_correction branch worked. Unfortunately we're most likely _not_ going to be able to use it, because it is highly idealized for a certain kind of setup. I looked more deeply into bed leveling issues for rc_fix_leveling_maths and that is probably going to end up being merged if it passes muster. So you should try it and let us know whether it also produces better results.

[timeshell]

I'm sorry I haven't been responding. Waiting for a part for my printer. I'll be following up soon too.

[thinkyhead]

@timeshell That's okay. I'm looking at yet another refinement where we may use the probed points along with the probe Z offset to perform a height correction, and also use the center of the probe region as the fulcrum for the tilted plane. Combining these two methods should lead to the smallest error and the most accurate distance to the bed, presuming that the M851 offset is set accurately and the probe is reliable. I may add that to my branch later on, but please feel free to still test it in the meantime.

[Frostyybeer]

@thinkyhead I will keep on testing the RCBugfix and rc_fix_leveling_maths branches once I have my 3Dprinter available again (just recently move back to my college dorm.)

[boelle]

@Frostyybeer Got your printer back or will it be a while yet?
@timeshell had time to revisit this subject?

[timeshell]

Not directly, but have discovered a couple things working with a client. I have a couple things to test which might narrow it down. I'll get to it in the next few days.

[timeshell]

Ok. Here is where I am at. I managed to get the offset to work in RC7.

I have two copies of the RC7. One with a config that doesn't work and one with a config that does. It seems to be specifically related to something happening within the configuration.h file. I am going to compare these two configurations and see if I can find the culprit.

[timeshell]

In RC7 Marlin_main.cpp line 3059-3061:

destination[X_AXIS] = round(Z_SAFE_HOMING_X_POINT - (X_PROBE_OFFSET_FROM_EXTRUDER));
destination[Y_AXIS] = round(Z_SAFE_HOMING_Y_POINT - (Y_PROBE_OFFSET_FROM_EXTRUDER));
destination[Z_AXIS] = current_position[Z_AXIS]; // Z is already at the right height

Why is the offset not being applied to Z with safe homing enabled? It says Z is already at the right height but I'm not so sure that it is. And the reason I ask is Z_SAFE_HOMING is enabled in the one that is not working and is not enabled in the one that is working.

[thinkyhead]

@timeshell What offset did you have in mind? When Z safe homing is done, it happens after homing X and Y. If there's a setting for Z_HOMING_HEIGHT that raise occurs _before_ homing X or Y. So by the time the blocking move to the safe homing XY occurs, the Z axis will already be off the bed. The homing of the Z axis itself will then occur after it makes room for the probe, if there is one.

[thinkyhead]

I'm actually patching Z safe homing a little at the moment. It can be used when there isn't a probe, so it needs a tweak in consideration of that.

[timeshell]

@thinkyhead The extruder Z offset? Same as the X/Y in that block of code? The Z_SAFE_HOMING was the only significant difference between the two configurations. I can email them to you if you'd like to compare.

I'm guessing after your second comment that you follow where I'm coming from. Yes, I use a probe and I'm guessing that's where it's breaking for probe users who are doing Z_SAFE_HOMING.

[timeshell]

Ok. Here's a question. If that code is assuming that the user isn't using a probe, why are the probe offsets being applied to X and Y then? Just curious now.

[thinkyhead]

The code currently assumes the user _is using a probe_. That's what I am changing, because we no longer require either a probe or auto bed leveling for the use of z safe homing.

[timeshell]

Out of curiousity, is any further testing required about this or has this issue been specifically identified now?

[thinkyhead]

It's probably worth giving RCBugFix another try to see how it's behaving. There's been a lot of cleanup in this area lately.

[boelle]

@timeshell did you retest RCBugfix?

[timeshell]

It appears to be working in the current RCBugFix with Z_SAFE_HOMING enabled.

[Frostyybeer]

@thinkyhead Update: I recently flashed my custom coreXZ-3Dprinter with RC8 version of Marlin and everything works as intended. I have NOT come across any problems/issues so far.

On a side note, I really appreciate the work and effort the development team had put into this opensource firmware. Please keep up the amazing work!