[BUG] Bed offset issues - TAP

[M3HNGRY]

I know you don't have TAP and maybe its an issues when it got updated.

This only happens with Variable Bed Surface Enabled.

I have enable Texture Sheet with offset of .79 for TAP. It is activated and loaded with offset .79

When I start my print after bed mesh. The nozzle hit the bed. To fix this. I have to add .015 to the offset while printing to get the correct first layer. Offset now is .805

Once the print is finish and I start a new one. Does it's bed mesh and start printing. Nozzle is to low and I have to adjust it again. Adding about .105 and now offset is about .82 and it keeps going...

[jschuh]

Sorry, I just don't think I understand this report. Could you please attach your config and the relevant parts of the log?

[BeardedBucket]

Given the number of config files associated with this repo which ones exactly would help? I too am having issues with getting stacking offsets even with a single surface, default, when I babystep via my my klipperscreen and then save the offset on my next print it seems its adding the original offset generated and saved in the config file as well as a surface offset leaving me printing far off the bed, which I suppose is better than digging in ruining a bed and possibly my nozzle. This is also with TAP. I would like to get this working so I can feel comfortable setting up additional surfaces but if I cant get one working correctly I am forced to just disable it.

[M3HNGRY]

^ x2 what he said….

[jschuh]

Assuming the files from this repo haven't been modified (which they shouldn't), then I don't need any of them attached, because they're already in this repo. In order to help, what I need to know is what other things in your config are altering the printer state. Because it sounds like the issue is either from conflicting overrides of SET_GCODE_OFFSET or something unexpectedly calling RESTORE_GCODE_STATE and messing up the offset. But I looked at the official Voron TAP configuration when this was filed last week, and it doesn't have anything like that. So, without your logs and/or configs—specifically the printer.cfg and any included configs from outside this repo—it's simply impossible for me to have any idea what your configuration issue is.

Bigger picture: mixing macros from different sources tends to lead to very difficult to diagnose issues (it's a sad artifact of how macros work). That's why there's a big warning about this at the top of the readme:

You really should avoid custom macros like this until you're comfortable using Klipper with a basic config. Advanced Klipper macros tend to rely extensively on monkey patching, which can lead to problems with unusual configurations or when mixing macros from various sources. So, you really want to know what you're doing before including someone else's macros—particularly when including macros with overlapping functionality from different sources.

And separate from all of that, these sorts of config help requests really belong in the Q&A discussion, rather than as bugs. I considered moving it there when it was filed, but the initial report was confusing enough that I figured it wouldn't be helpful.

[BeardedBucket]

I think you are right that this is unlikely to be an actual bug but rather a conflict. I suspect in my case because of the way klipperscreen works, the lcd menus do not work with it so no surface management at the moment, that when doing an adjustment and then save_config that it is calling both the surface to update and updating the default offset. If I just go in and manually set surface offset to 0.0 after adjusting its fine but not working as I am sure intended.

I believe you are right that this is not a bug and likely just a config issue. I will attach my printer and variables config, I am not the original poster but I would understand if you closed it. config-202341-398.zip klippy (1).log

[jschuh]

If your SAVE_CONFIG adjusts any of the Z offsets (probe, endstop, etc.) then you should get a console warning at printer startup informing you that you need to run ADJUST_SURFACE_OFFSETS. You could also just put ADJUST_SURFACE_OFFSETS in the gcode section of your [gcode_macro _km_options] to always run it at startup.

Looking at your config, it has a probe offset of -0.770, but the variables.cfg file has a saved offset of -0.39. So, those are definitely out of sync.

Is this problem happening only after running SAVE_CONFIG? Also, why would you run SAVE_CONFIG beyond the initial setup of your probe? The probe offset doesn't change unless you physically move the probe hardware. The idea is that you run SAVE_CONFIG only once, when you install the probe or endstop (ideally with the gcode offset set to 0). After that you just use the normal gcode offset adjustments to fine tune the offsets for different surfaces, and the macros implicitly save those for the currently selected surface (without running SAVE_CONFIG).

[M3HNGRY]

I adjust mine using live z-offset. Don't get any warning at printer startup informing that we need to run ADJUST_SURFACE_OFFSETS.

klippy.log config-202350-21423.zip

[jschuh]

Okay, you absolutely need to calibrate the probe z_offset to the correct physical distance. The Klipper code uses the true physical probe position for things like homing, probing, meshing, and all limit checking. So, if that z_offset is incorrect you're going to end up crashing into the bed. This goes for all manner of probes, but is particularly critical when you're relying on the probe as the virtual_endstop. This is just how Klipper works.

Before your initial calibration I would suggest first setting the current surface offset to zero using SET_SURFACE_OFFSET OFFSET=0 and ideally using the smoothest bed surface you have (textured sheets can be a bit less precise for calibrating the z_offset). This just leaves less room for numerical error to creep in. After calibrating I would also suggest restarting the printer and calibrating again from that previous baseline. This has to do with how homing and microstepping work, and the more accurate the z_offset the less likely you'll have problems later.

After that you should be relying on the surface system solely for fine tuning heights for different surfaces and storing saved meshes for a given surface. Since you have a virtual_endstop configured I'd be surprised if you ever need a bed surface offset of more than +/- 0.1. Among my printers with a virtual_endstop, the largest offset I have is 0.075, and that's for a surface with diffraction grating where I'm intentionally really over-squishing to get the pattern pressed into the surface. For every other surface on those machines the offset is within +/- 0.02

One unrelated note: You'll want to remove that [include mainsail.cfg] line from your printer.cfg. All the functionality from that file is already provided by the macros in this repository, and including both at the same time can cause problems.

[M3HNGRY]

Thank you for the clarity and explanation of how things work.

I have removed [include mainsail.cfg] line from your printer.cfg and SET_SURFACE_OFFSET OFFSET=0. Then HOME ALL and QGL. Then I ran PROBE_CALIBRATE. After that I set my Smooth and Texture sheets.

I have attached my logs and configs to verify that's correct now? Could I buy you a cup of coffee for all the help and great Macros that you supplied us?

Thank you so much! Anthony

klippy (1).log config-202351-171230.zip

[jschuh]

Is it working properly now? Because the offset values in variables.cfg still seem much too high given that you're using TAP. Those values are really more in line with a physical endstop, or capacitive/inductive probes, which don't actually measure the position of the surface you're printing on. Instead they measure the position of the frame (physical) or the position of the metal sheet that the print surface is stuck to (capacitive/inductive). That's why you need something like the surfaces feature to account for that difference when you're using multiple different surfaces/sheets.

But with things like TAP and BLTouch you're measuring the position of the actual physical surface you're printing on. That's why any surface offsets should be tiny. Because if you need any offset at all, it's just a fine adjustment to account for the minor deviations in the texture of the build surface. So, I just don't understand how you're getting surface offsets of 0.265mm and 0.155mm, and I'm very surprised at the 0.105mm difference between surfaces. Assuming the probe z_offset is correct, a surface offset of zero should be fine with something like TAP.

Is it possible that you're actually just sliding the toolhead up the TAP rail when you're trying to adjust the surface offset on the first layer? I could imagine that back pressure from the extruding filament could keep a light enough toolhead at the right height during that print, but then it may be too low the next time you try to print.

Or if everything is working okay then I guess it's fine. But I'm just very confused by those offsets.

[M3HNGRY]

Jschuh,

I am doing more testing and etc. I just upgraded to R8 Version of the Tap to see if it will be more accurate.

[M3HNGRY]

Still having issues... Not sure whats going on...

klippy (2).log

[M3HNGRY]

Seems like this happen to others. I ask some people on Voron Discord in the Voron_Tap section. Some recommended the below.

https://github.com/voidtrance/voron-klipper-extensions

Settling Probe
For some currently unknown reason, Voron printers seem to suffer from an issue where the first probing sample is off by some margin. Subsequent samples are much closer (or the same) to each other. The current theory is that there is some toolhead/axis settling on the first sample.

In order to avoid polluting the probe samples, the first sample should be thrown away.

This extension adds support for performing a single, throw-away, settling probe sample that is not part of the sample set used for calculating Z positions.

The extension replaces the default probe Klipper object with the modified one in order to allow all commands/operations that perform Z probing to benefit from this.

To enable the module, add the following to your printer.cfg file right after the [probe] section:

[settling_probe]
#settling_sample:
#   Globally enable the throw-away settling sample. Default is 'False'.
#   Setting this to 'True' will enable the throw-away sample for all
#   commands/operations that perform Z probing (QGL, Z tilt, Bed Mesh,
#   Screw Tilt, etc.)
The module also augments the PROBE, PROBE_ACCURACY, and PROBE_CALIBRATE commands with an extra parameter - SETTLING_SAMPLE - which can be used to control whether the commands perform a settling sample independently from the settling_sample setting.

[M3HNGRY]

Klipper issue

https://klipper.discourse.group/t/need-to-discard-the-first-probe-help-me-find-the-root-cause/7084

[jschuh]

All of that sure reinforces my thought that this is due to play in the physical configuration of the extruder/probe mechanism. Given that, I'm going to close this report out, since it just seems beyond the scope of what a macro can handle.

[M3HNGRY]

Jschuh,

how do we increase the probe count? Default is 3. I tried variable_probe_min_count: 4 but seems like it doesnt work.

V/R Anthony

[jschuh]

You may have the probe count confused with the sample count. Because, probe_min_count defines the minimum number of points the the generated grid must have in each dimension after scaling the bed mesh to the size of the print (the default minimum grid is 3x3).

I think what you want to tune is the sampling behavior, which determines how many samples Klipper takes at each probe point and how it handles those samples. That's all defined by a collection of variables in the probe config.

These macros don't do anything to alter the probe sampling behavior. It's just whatever is already defined in your config.

[M3HNGRY]

I just order a CNC TAP to see if this changes or not. Hopefully, this resolve my inconsistent z offset issues....

[VACIndustries]

@M3HNGRY I used the voron klipper extensions you posted above without issue on my printed V8 tap. It really helped me out

[M3HNGRY]

@M3HNGRY I used the voron klipper extensions you posted above without issue on my printed V8 tap. It really helped me out

Can you share how to implement it? (Post the printer.cfgs and etc where you modify? Thanks