Help me understand Z Offset issues

Basic Information:

Printer Model: Anycubic Kobra Max V1
MCU / Printerboard: Trigorilla Pro A v1.0.4
Host / SBC: RPI 3B+ Mainsail

Describe your issue:

Hi all, new Klipper user here. Setup a Pi few days ago and got my KMax setup with a combo of 2 public configs. So far its been smooth aside from nozzle eating the bed, and ive read through several posts about my printer specifically, as well as reading the documentation on leveling and I just can’t figure out how to setup Z Offset.
Its still a stock printer, so strain gauge setup on probe. I do “probe_calibrate” and “bed_mesh_calibrate” and save, but even in between print jobs the nozzle still ends up pushing into the bed enough to not extrude at all, and Its just been a constant battle of calibration and Klipper seamingly forgetting what it was calibrated to.
I set both the [probe] z offset and “saved config” offset to 0 and figured out my Z needs to be around .95 or 1.0, but adjusting it to that during a print is still the only way ive been able to print.

What am I missing? Is it something simple?

logs-20260814-172324.zip (2.3 MB)

  1. Home all axis.

  2. Move to the center X/Y position.

  3. Enter `PROBE_CALIBRATE’ from the Console input box and you should have something like the following with the “Manual Probe” window popping up:

  4. Putting a piece of paper below the nozzle.

  5. Moving the toolhead down until there is friction between the paper and the nozzle.

  6. Click on ACCEPT

  7. In the Console input box enter SAVE_CONFIG

  8. The printer will reboot. If you look at your printer.cfg file, you’ll see a commented out area at the end of the file that looks something like:

This is a copy-paste of a old suggestion on the forum of the exact steps ive done, and offset looks correct in the config but it still seems off whenever I go to print.

We don’t know what code you are running, as it is a fork of a fork (a modification of the modification).

Loaded MCU 'mcu' 128 commands (Kalico fba03257 / gcc: (15:14.2.rel1-1) 14.2.1 20241119 binutils: (2.44-3+23+b2) 2.44)
MCU 'mcu' config: ADC_MAX=4095 CLOCK_FREQ=168000000 MCU=HC32F460 PWM_MAX=65535 RECEIVE_WINDOW=192 RESERVE_PINS_serial=PA3,PA2 SERIAL_BAUD=250000 STATS_SUMSQ_BASE=256 STEPPER_OPTIMIZED_EDGE=21 STEPPER_STEP_BOTH_EDGE=1
Configured MCU 'mcu' (1024 moves)
Args: ['/home/catboat/klipper/klippy/klippy.py', '/home/catboat/printer_data/config/printer.cfg', '-I', '/home/catboat/printer_data/comms/klippy.serial', '-l', '/home/catboat/printer_data/logs/klippy.log', '-a', '/home/catboat/printer_data/comms/klippy.sock']
App Name: Kalico
Git version: 'fba03257'
Branch: main
Remote: origin
Tracked URL: https://github.com/printers-for-people/catboat

Otherwise, I don’t see anything suspicious in the config, but I can suggest you try setting the zero_reference: Bed Mesh - Klipper documentation

Also, normally, it is expected that you do a coarse PROBE_CALIBRATE, and then fine-tune it with baby stepping, which can later be saved to z_offset.

For example: V-Core 3.1 Commissioning Guide | Rat Rig Wiki
Look at the z_offset/first layer sections.

Hope that helps,
-Timofey

While I looked into both of those links, It really wasn’t anything I haven’t already done.

Im now having to set Z offset in the negative numbers to get it to actually stick to the bed, Its just frustrating because it was working better in marlin.

What is it about my bed mesh that just isnt being accounted for during initial printing?

What are you using for the probe? Your mesh (I only looked at your last config #6) is very wonky with a 1.3mm range.

I’d guess your probe is misconfigured or has electrical/mechanical issues,

Its still stock, so its the built in strain gauge tap probe, and yeah variance is up to 1.6 now with my latest mesh reading. Part of that is def warped bed but that’s why im trying to get it dialed in to compensate.

How does the probe do on

From what I recall it actually did pretty good? Iv got a print going now but iirc the values last times were all within 0.0025 of the initial points.
Ill have to run it again to be sure, but I do recall being happy with the output the first time or 2 I ran that test