Closed xaviervilla closed 6 days ago
Nuck-TH
commented
1 week ago I reproduce it on Kingroon KP3s with current bugfix. Changing offset directly, using wizard or babystepping it doesn't change first layer thickness at all, it is always the same. Configuration.zip
xaviervilla
commented
1 week ago Interesting. ~Babystep live during the first layer did work for me, but saving to EEPROM after the print did not solve the issue when I went to reprint.~ (Edit for clarification: realized I was just using regular babystepping z, not z offset.)
I spent a significant amount of time trying to figure out if it was me doin something wrong but I’m pretty confident now that there is a bug here. This is my first time ever using ABL though so maybe I’m missing something.
In the meantime, I may try manually moving to the Z height I need in my g code and then setting the current position to zero before my print. I believe that should be a temporary workaround for people who need to print.
ThomasToka
commented
1 week ago Have you tried to enable those two already?
#define BABYSTEP_ALWAYS_AVAILABLE
#define BABYSTEP_ZPROBE_OFFSETBABYSTEP_ZPROBE_OFFSET was already enabled, BABYSTEP_ALWAYS_AVAILABLE did nothing to change situation.
xaviervilla
commented
1 week ago Apologies, I was adjusting babystep during my first layer, not BABYSTEP_ZPROBE_OFFSET. I have BABYSTEP_ZPROBE_OFFSET disabled. So I cannot verify if I had the same or different behavior as what @Nuck-TH described with babystepping Although they definitely seem related. I could enable it and try that too but I would need to make some custom GCODE because I've pretty much destroyed my bed trying to sort this out.. I have a little time to dig into the code and check recent commits now.
xaviervilla
commented
1 week ago Looks like this was added to G29. Looking into why.
// Unapply the offset because it is going to be immediately applied
// and cause compensation movement in Z
const float fade_scaling_factor = TERN(ENABLE_LEVELING_FADE_HEIGHT, planner.fade_scaling_factor_for_z(current_position.z), 1);
current_position.z -= fade_scaling_factor * bilinear_z_offset(current_position);Okay after looking through the G29 code, I decided to try G29 Z5 and that made the nozzle 5MM off the bed when Z showed zero on the build plate. And my Mesh shows:
0 1 2 3 4
0 +5.307 +5.170 +5.150 +5.148 +5.280
1 +5.175 +5.035 +5.010 +5.028 +5.090
2 +5.145 +5.015 +5.012 +4.990 +5.035
3 +5.193 +5.052 +5.043 +5.045 +5.080
4 +5.195 +5.160 +5.145 +5.133 +5.140I believe this is to be expected from the documentation I read.
I don't see anywhere in the G29 code that looks like it is applying the offset from the EEPROM/config value, but only from the gcode command itself. Is this expected?
I'm thinking I should look into the M851 code now.
robherc
commented
1 week ago I expect that with a z probe offset of -2, my nozzle is too high off the build plate when I do G0 Z0 but Nozzle crashes at Z = 1. I would expect that with a Z probe offset of -5, my nozzle is WAY too high off the build plate when I do G0 Z0 but nozzle crashes at Z = 1 again.
I haven't read through your configs yet, but I ### did### notice a slight problem with your logic here. The more negative you set your PROBE_Z_OFFSET, the further BELOW the prob's trigger-point you're telling Marlin to move to get the nozzle to Z=0.
Will you please attempt setting your Z_PROBE_OFFSET to +2mm; then re-home; then G1 X110 Y110 Z0.1 F1500
If the Z_PROBE_OFFSET is being applied, that should most DEFINITELY end motion with ths nozzle a few mm above your bed surface.
xaviervilla
commented
1 week ago Will you please attempt setting your Z_PROBE_OFFSET to +2mm; then re-home; then
G1 X110 Y110 Z0.1 F1500If the Z_PROBE_OFFSET is being applied, that should most DEFINITELY end motion with ths nozzle a few mm above your bed surface.
I did try positive values as well, but I’ll give it a shot again and respond with what happens. Thanks for the feedback. I got mixed up when I posted that, (it was about 2am and I was tired). But I agree with you, the expectation should have been that with -5 offset the nozzle crashes at an earlier point (z=4 in that example). But it continues to crash at Z=1 each time, regardless of the Z offset.
xaviervilla
commented
6 days ago @robherc I initially followed your instructions and then got the same behavior I mentioned.
; Probe the bed
G29
...
0 1 2 3 4
0 +0.253 +0.138 +0.123 +0.112 +0.255
1 +0.148 +0.018 -0.005 -0.007 +0.065
2 +0.120 -0.005 +0.003 -0.048 -0.018
3 +0.140 +0.035 +0.028 +0.000 +0.060
4 +0.235 +0.135 +0.118 +0.128 +0.125
X:235.00 Y:221.00 Z:11.55 E:0.00 Count X:18800 Y:17680 Z:4620
ok
; Set Positive Z probe offset
M851 Z2
ok
M500
echo:Settings Stored (682 bytes; crc 49771)
//action:notification Settings Stored
ok
; Move to bed center
G1 X110 Y110 Z5 F1500
echo:busy: processing
ok
; Incrementally lower nozzle
G1 Z3
ok
G1 Z2
ok
G1 Z1
; Nozzle is already pressed into the bedAnd then I re-read what you said. You said to home again after setting the Z offset. I tried again, homing right after setting the Z offset and to my disbelief it worked. Persists reboots as well. The final z probe offset value I needed was -1.4. First print is going down great now.
I feel very dumb for not figuring that out on my own. Looking through my command history and even the gcode in the original post, I was not homing each time between my tests. Oddly, the prints that tried trying were homing so I don't know why those changes didn't seem like they were applying, but it was probably something I was doing wrong. My other source of confusion is that I thought I was babystepping Z probe offset and storing to EEPROM during my prints. But I was actually just adjusting regular babystep Z which is different and does not get stored to EEPROM at all.
Users must home after setting the z probe offset for it to be applied and take effect. While I am tempted to close this issue, I'll leave it open for a dev to close at their discretion with this closing remark:
On the Marlin Documentation on M851, there is no mention that homing is required after setting the Z offset. In fact, in the videos I watched online, there was also no mention of this. Is this new? If this is the desired behavior I believe that it should definitely be documented better on the M851 page. Otherwise, I think it makes the most sense for M851 to automatically apply the Z offset immediately.
Thank you to all who helped.
robherc
commented
6 days ago Users must home after setting the z probe offset for it to be applied and take effect.
Actually, this is because you disabled the babystepping for z_probe_offset. When that is enabled, while it may still be recommendable to re-home after the adjustment, it is generally not necessary, as the printer is babystepping to "live-apply" the new Z-Offset as you adjust the setpoint.
Did you test the latest
bugfix-2.1.xcode?Yes, and the problem still exists.
Bug Description
Z Offset with ABL (BIQU_MICROPROBE_V2) has no effect on the physical height of the nozzle at specified Z Values. i.e. Offset of -2 and -10 both result in nozzle crashing into bed at Z = 1.
This is a separate issue but I will mention it here because it is possibly related: I tried to use PROBE_OFFSET_WIZARD but it gave strange undefined behavior even after wiping EEPROM and reinitializing so I disabled it. I would use it to find a z offset around -1.4 and when I hit done the Z Offset would then show ~36.x offset.. All subsequent "G29" procedures after this action resulted in "Probe Failed".
Bug Timeline
Oldest commit I saw this behavior was 70ef7978b418691904b1fe70f6c1009295eb5f7f
Expected behavior
I expect that with a z probe offset of -2, my nozzle is too high off the build plate when I do
G0 Z0but Nozzle crashes at Z = 1. I would expect that with a Z probe offset of -5, my nozzle is WAY too high off the build plate when I doG0 Z0but nozzle crashes at Z = 1 again. I haveENABLE_LEVELING_AFTER_G28defined, and it appears to work as intended because bed leveling always shows "on" in the menus.Actual behavior
Different Z probe offset values make no difference to height of nozzle at Z=0.
Steps to Reproduce
Version of Marlin Firmware
M115 FIRMWARE_NAME:Marlin bugfix-2.1.x (Oct 30 2024 00:14:03) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-3 Pro KINEMATICS:Cartesian EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff Cap:SERIAL_XON_XOFF:0 Cap:BINARY_FILE_TRANSFER:0 Cap:EEPROM:1 Cap:VOLUMETRIC:1 Cap:AUTOREPORT_POS:1 Cap:AUTOREPORT_TEMP:1 Cap:PROGRESS:0 Cap:PRINT_JOB:1 Cap:AUTOLEVEL:1 Cap:RUNOUT:0 Cap:Z_PROBE:1 Cap:LEVELING_DATA:1 Cap:BUILD_PERCENT:1 Cap:SOFTWARE_POWER:0 Cap:TOGGLE_LIGHTS:0 Cap:CASE_LIGHT_BRIGHTNESS:0 Cap:EMERGENCY_PARSER:1 Cap:HOST_ACTION_COMMANDS:1 Cap:PROMPT_SUPPORT:1 Cap:SDCARD:1 Cap:MULTI_VOLUME:0 Cap:REPEAT:0 Cap:SD_WRITE:1 Cap:AUTOREPORT_SD_STATUS:1 Cap:LONG_FILENAME:1 Cap:LFN_WRITE:0 Cap:CUSTOM_FIRMWARE_UPLOAD:0 Cap:EXTENDED_M20:1 Cap:THERMAL_PROTECTION:1 Cap:MOTION_MODES:0 Cap:ARCS:1 Cap:BABYSTEPPING:1 Cap:EP_BABYSTEP:0 Cap:CHAMBER_TEMPERATURE:0 Cap:COOLER_TEMPERATURE:0 Cap:MEATPACK:0 Cap:CONFIG_EXPORT:0 ok
Printer model
Modified Ender 3 Pro
Electronics
BTT SKR Mini E3 V3
LCD/Controller
Stock LCD
Other add-ons
BIQU MicroProbe V2, Sprite Direct Drive Extruder, Phaetus Dragon UHF
Bed Leveling
ABL Bilinear mesh
Your Slicer
Prusa Slicer
Host Software
Other (explain below)
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
My config diff of the SKR mini e3 v3 configs here:
https://github.com/MarlinFirmware/Configurations/commit/e8b69f0882acd6ea8999104151e5c79aec4d0b15
My config diff compared to the default config in the Marlin repo if that is helpful at all:
https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.1.x...xaviervilla:Marlin:z-offset-fix_bugfix-2.1.x
Config files:
Configs.zip
I embedded a bunch of GCode above that can be utilized for testing (in steps to reproduce section).