Trying to get my dad's printer working again, but stuck on first-layer/Z-offset issues

General Discussion
1

Basic Information:

Printer Model: Creality Ender 3 Pro
MCU / Printerboard: 4.2.2
Host / SBC Raspberry Pi running Klipper/Mainsail
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hi everyone,

I’m hoping someone can help me get my dad’s Ender 3 Pro working again. I installed Klipper/Mainsail to improve the printer, but I haven’t been able to get a successful print since switching from the stock OS.

I’m comfortable following technical instructions, but I’m still learning Klipper and would really appreciate some guidance from someone experienced with Ender 3 + BLTouch setups.

Setup

  • Printer: Creality Ender 3 Pro

  • Mainboard: Creality 4.2.2 32-bit

  • Host/SBC: Raspberry Pi

  • Software: Klipper + Mainsail

  • Probe: BLTouch

Problem

Mainsail connects and Home All works successfully, but the nozzle/first layer isn’t printing correctly onto the build plate.

During earlier troubleshooting, I accidentally crashed the nozzle into the plate, leaving a permanent dent. I’m not sure whether the nozzle was damaged or pushed upward, so I’ve been hesitant to keep experimenting and risk another crash.

I found my existing printer.cfg from February 6, 2026. One thing that immediately caught my attention is:

[bltouch]
sensor_pin: ^PB1
control_pin: PB0
x_offset: -45
y_offset: -5
#z_offset: 0.0

And the saved configuration contains:

#*# [bltouch]
#*# z_offset = 0.0

There is also an existing 12x12 bed mesh.

What I’m hoping to figure out

Could someone look at my configuration and help me determine:

  • Is the BLTouch/Z configuration correct?

  • Does the z_offset = 0.0 need to be calibrated?

  • Should I redo the bed leveling/mesh?

  • Could the previous crash have damaged the nozzle?

  • What is the safest order of steps to get this printing correctly without crashing the nozzle again?

My main goal is simply to get my dad’s printer working reliably again. I’m happy to do the troubleshooting myself; I just need some experienced guidance on what to do and in what order.

I’ve included my printer.cfg and klippy.log below. Thanks to anyone willing to take a look!

printer.cfg:

[PASTE PRINTER.CFG HERE]

klippy.log:

ATTACH KLIPPY.LOG HERE

klippy.log (133.0 KB)

…

2

Hello @NOprintingJustconfig and welcome to the forum!

Some questions:

Is this a genuine antclabs BLTouch?
In any case, you may read here: BL-Touch - Klipper documentation

Most probes have to be calibrated: Probe calibration - Klipper documentation
In the end, in most cases the z_offset wont be 0.0 any more.

Depends on the crash. But most nozzles are quite sturdy. You may can make a photo and post it here.

First start is this: Configuration checks - Klipper documentation
For fine tuning there is Welcome! | Ellis’ Print Tuning Guide

3

Welcome NOprintingJustconfig,

is this your first 3d printing experience?

4

Also see:

5

Thanks for the welcome and for the guidance.

I should clarify the probe: I have the Creality CR Touch Auto Leveling Kit, specifically the one sold by Creality for the Ender 3/Ender 3 Pro with the 4.2.2/4.2.7 32-bit boards. I chose the CR Touch rather than a BLTouch because I preferred the metal probe pin.

I did actually try calibrating the Z offset previously using the paper/sticky-paper method. The problem was that the resulting numbers seemed very far off, and unfortunately I don’t remember exactly what values I ended up with. That’s part of why I stopped rather than continuing to experiment after already having one nozzle crash.

The crash wasn’t extremely violent, but the nozzle hit the build plate hard enough to leave a permanent dent. I haven’t been able to determine whether the nozzle was damaged or pushed upward afterward.

The other thing that confused me is that my saved configuration currently has:

bltouch

sensor_pin: ^PB1
control_pin: PB0
x_offset: -45
y_offset: -5
#z_offset: 0.0

and then in the SAVE_CONFIG section:

## [bltouch]
## z_offset = 0.0

So I wasn’t sure whether the 0.0 meant the probe had never actually been calibrated, or whether that was a valid value that had simply been saved.

I’m going to do another careful calibration test and record the actual values/results this time.

Would you recommend that I first verify the CR Touch configuration and operation, then run PROBE_CALIBRATE, and only afterward deal with bed tramming and generating a new mesh? I’m trying to establish a safe baseline before making any more changes so I don’t repeat the nozzle crash.

Thanks again for the help.

6

Thanks! I’m not completely new to 3D printing. I’ve worked with my dad’s Ender 3 Pro before, but I am relatively new to Klipper and Mainsail.

The printer worked with its original setup, and I installed Klipper/Mainsail because I wanted to improve it. I also installed a Creality CR Touch for automatic bed leveling.

I’m comfortable following technical instructions and troubleshooting, but I’m still learning how Klipper handles things like probe calibration, Z offsets, and bed meshes. My main goal right now is to get back to a known-good baseline without causing another nozzle/bed crash.

7

Quick update based on the suggestions so far:

I did some additional testing before attempting another Z-offset calibration.

The printer is using a Creality CR Touch on an Ender 3 Pro with the Creality 4.2.2 board. My current relevant configuration is:

stepper_z

endstop_pin: probe:z_virtual_endstop
position_min: -5
position_max: 250

bltouch

sensor_pin: ^PB1
control_pin: PB0
x_offset: -45
y_offset: -5
probe_with_touch_mode: true
stow_on_each_sample: false

safe_z_home

home_xy_position: 155, 115
speed: 75
z_hop: 10
z_hop_speed: 5

I first tested the CR Touch manually. BLTOUCH_DEBUG COMMAND=pin_down successfully deployed the metal probe pin. When I manually pushed the pin back up, QUERY_PROBE reported probe: TRIGGERED. After BLTOUCH_DEBUG COMMAND=reset, the probe retracted, the LED returned to blue, and QUERY_PROBE reported probe: open.

I then moved the head to Z20 with:

G90
G1 Z20 F300

GET_POSITION confirmed:

X:155 Y:115 Z:20

From there I ran G28 Z while watching the CR Touch.

The CR Touch deployed, Z began moving down, and the probe pin contacted the bed. However, the nozzle shortly afterward also contacted the bed. The printer then moved back up, went back down again, and finally moved back up and stopped. There was no Klipper error reported.

So at this point it appears the CR Touch is communicating with Klipper and is being used during Z homing, but the nozzle is still making contact with the bed during the homing sequence.

I have not attempted another Z-offset calibration or changed the probe_with_touch_mode setting.

Any suggestions on what I should check next would be appreciated. I’m trying to avoid another hard nozzle crash before proceeding with PROBE_CALIBRATE.

8

Thanks for the suggestion. I actually tried the paper test earlier when I was working on the Z offset, but I was still having issues with the resulting numbers and wasn’t confident they were correct.

I’ve since done some additional testing with the CR Touch and found that it’s communicating with Klipper, but I’m still having an issue during Z homing where the nozzle makes contact with the bed. I’m trying to get that sorted out before attempting the paper test again.

9

@NOprintingJustconfig :
When posting code, please use the Preformatted text feature of the forum editor. Else the code looks messy and is maybe wrong.
Format

10

It sounds to me like your probe is mounted too high. That type probe has a non adjustable “trigger point” 2-3 mm after it first touches. The probe MUST get to the trigger point before the nozzle gets to the bed.

Put a stack of washers under the probe or remove the nozzle and home again. Watch the LED change when the probe triggers.

The Z offset doesn’t change the probes datum point, it tells klipper the distance between the probe datum point and the nozzle tip.

11

That makes sense, and I didn’t think about the CR Touch having a specific mechanical trigger point like that.

The only reason I’m hesitant to think the probe is mounted too high is that this exact CR Touch and mounting setup worked correctly with the stock Creality firmware. We had quite a few successful prints before I switched the printer over to Klipper, so as far as I know the physical mounting was correct before.

I understand now that the Z offset doesn’t change when the probe actually triggers, so I don’t want to try using the Z offset to fix a possible mounting problem.

Since I’ve already had one nozzle crash, I think removing the nozzle and testing the Z homing is probably the safest way to check this. I’ll watch the CR Touch LED and see exactly when it triggers and what happens afterward.

Thanks for explaining the trigger point. I think this gives me a safer way to figure out what’s actually wrong before I start changing the probe mounting or Z offset.

12

Update: I did some additional testing of the CR Touch

Thanks everyone for the suggestions so far. I spent some more time testing the printer and have narrowed things down a little. I’m not sure on the preformatted text so please excuse this post if it looks wrong.

First, I confirmed that this is actually a Creality CR Touch, not an Antclabs BLTouch. It is the Creality CR Touch kit designed for the Ender 3 Pro/4.2.2 board. The probe worked normally under the original Creality firmware, and we had numerous successful prints with it before I switched the printer to Klipper.

I also tried the paper test previously, but the Z-offset numbers I got seemed completely wrong/out of whack, so I didn’t save a new offset.

Here is what I’ve been able to confirm with Klipper:

BLTOUCH_DEBUG COMMAND=pin_down successfully deploys the probe.

With the pin deployed, QUERY_PROBE reports:

probe: open

If I manually trigger the probe pin, QUERY_PROBE changes to:

probe: TRIGGERED

BLTOUCH_DEBUG COMMAND=reset returns the probe to its normal retracted state and QUERY_PROBE reports:

probe: open

So the probe can physically deploy and Klipper can detect its triggered state.

The problem happens during actual Z homing.

During my previous G28 test, the CR Touch deployed and the probe pin physically contacted the bed. However, the Z axis continued moving downward instead of stopping immediately. The nozzle then contacted the bed, the head backed up, and it attempted the probing movement again before eventually stopping.

Obviously I don’t want to keep repeating this test because I don’t want to damage the nozzle or bed.

I also posted my complete printer.cfg. The relevant configuration is:

[stepper_z]

step_pin: PB6

dir_pin: !PB5

enable_pin: !PC3

microsteps: 16

rotation_distance: 8

endstop_pin: probe:z_virtual_endstop

position_min: -5

position_max: 250

[bltouch]

sensor_pin: ^PB1

control_pin: PB0

x_offset: -45

y_offset: -5

#z_offset: 0.0

probe_with_touch_mode: true

stow_on_each_sample: false

[safe_z_home]

home_xy_position: 155, 115

speed: 75

z_hop: 10

z_hop_speed: 5

The saved configuration still has:

#*# [bltouch]

#*# z_offset = 0.0

So I know the probe Z-offset has never been successfully calibrated under Klipper.

At this point I’m wondering whether the next thing to investigate is why the CR Touch’s trigger signal works with QUERY_PROBE but doesn’t appear to stop Z during the actual homing sequence.

I haven’t changed probe_with_touch_mode, the probe offsets, or the physical mounting yet. Since the CR Touch worked correctly with the stock firmware, I’m hesitant to physically remount it without first ruling out a Klipper configuration/signaling issue.

Any suggestions for the safest next diagnostic would be greatly appreciated.

13

The default for probe_with_touch_mode is false.

14

Quick update after additional troubleshooting.

Today’s testing produced some useful results.

Printer:

  • Ender 3 Pro
  • Creality 4.2.2
  • BLTouch
  • Klipper + Mainsail

Verified:

  • BLTouch deploys and retracts correctly
  • BLTOUCH_DEBUG COMMAND=pin_down works
  • BLTOUCH_DEBUG COMMAND=pin_up works
  • BLTOUCH_DEBUG COMMAND=reset works

QUERY_PROBE testing:

  • Returns “open” normally
  • Returns “TRIGGERED” when manually activating the probe pin

XY Homing:
G28 X Y completes successfully.

Z Homing:
G28 Z moves to center, deploys the BLTouch, and lowers toward the bed.

Observed behavior:

  • BLTouch pin physically contacts the bed
  • Probe LED changes state (red)
  • Printer continues moving downward
  • Nozzle crashes into the bed
  • Emergency Stop required

Based on today’s testing, Klipper appears able to see the probe state using QUERY_PROBE, but the Z homing move does not stop when the probe triggers during G28 Z.

Current BLTouch settings:

bltouch

sensor_pin: ^PB1
control_pin: PB0
probe_with_touch_mode: true
stow_on_each_sample: false

Any suggestions on why QUERY_PROBE responds correctly but G28 Z ignores the trigger during the homing move?

15

Please post a fresh klippy.log following the above testing.

16

Backup_klippy_09052026.log (1.3 MB)

Here is the klippy.log

17

You still have it set to true:

[bltouch]
sensor_pin = ^PB1
control_pin = PB0
x_offset = -45
y_offset = -5
probe_with_touch_mode = true
stow_on_each_sample = false
z_offset = 0.0
18

Thanks for pointing that out. I went ahead and changed probe_with_touch_mode from true to false and performed some additional testing.

QUERY_PROBE appears to behave correctly. It reports open normally and reports TRIGGERED when I manually activate the BLTouch pin.

I also performed a physical inspection and attached a photo. With the probe deployed, the BLTouch pin clearly extends lower than the nozzle. Using a ruler, I confirmed that the BLTouch triggers (red LED and probe retracts) before the nozzle contacts the ruler.

After changing probe_with_touch_mode to false, I ran G28 X Y followed by G28.

The printer homes X and Y normally and moves to the safe Z home position. During Z homing, I observe the following:

  • The probe deploys.
  • The probe contacts the bed.
  • The BLTouch LED turns red, indicating the probe appears to trigger.
  • The nozzle continues slightly farther downward before lifting.
  • The printer repeats this cycle about three times.
  • The printer then lifts up and does not enter a shutdown state.

Unlike my earlier testing, I no longer need to use Emergency Stop and Klipper does not report any errors or shutdowns.

After homing, GET_POSITION reports:

toolhead: X:155.000000 Y:115.000000 Z:10.000000

which makes me think Klipper believes the homing process completed successfully.

My concern is that when the BLTouch LED turns red during probing, the nozzle appears to continue a little farther downward before lifting away. I’m trying to determine whether that slight additional movement is normal behavior during probing or whether it indicates there is still a BLTouch/probing issue.

Does this now look more like a Z-offset/probe calibration problem, or do you still see evidence of a BLTouch configuration or homing issue?

I’ve attached a photo showing the deployed probe position relative to the nozzle.

PXL_20260908_175652332
PXL_20260908_1756523321920×2560 648 KB

19

Thanks for the suggestion regarding probe_with_touch_mode.

I changed probe_with_touch_mode from true to false and continued testing.

Additional findings:

  • QUERY_PROBE works correctly.
  • QUERY_PROBE reports open normally.
  • QUERY_PROBE reports TRIGGERED when I manually activate the BLTouch pin.
  • The BLTouch deploys, retracts, and resets correctly.
  • I physically inspected the probe and confirmed the deployed probe pin extends lower than the nozzle.
  • Using a ruler, I confirmed the BLTouch triggers and retracts before the nozzle touches the ruler.
  • I attached a photo showing the deployed probe relative to the nozzle.

After changing probe_with_touch_mode to false, I ran G28 X Y and then G28.

The behavior changed compared to my earlier testing:

  • Printer homes successfully without entering a shutdown state.
  • Probe deploys and contacts the bed.
  • BLTouch LED turns red during probing.
  • The printer lifts and repeats the probing cycle several times.
  • Homing completes and GET_POSITION reports valid coordinates.

After that, I ran PROBE_CALIBRATE.

The calibration routine started successfully and brought me into the manual paper test. I lowered the nozzle until a sheet of paper had a slight drag and then selected ACCEPT.

Klipper reported:

bltouch: z_offset: -0.620

However, when I ran SAVE_CONFIG, Klipper failed to restart and now reports:

Option 'z_offset' in section 'bltouch' must have minimum of 0.0

So at the moment Klipper will not start because the saved BLTouch z_offset is negative.

My current understanding is that we may have moved beyond the original homing/shutdown issue and into probe calibration / Z-offset territory, but I’m not sure why PROBE_CALIBRATE resulted in a negative BLTouch z_offset.

Does the negative value suggest that I performed the calibration incorrectly, or does it indicate there is still another configuration issue that needs to be corrected before the BLTouch can be calibrated properly?

20

The picture that you shared shows as stated by you as deployed which is incorrect it need to retracted not deployed.

A negative value means your nozzle is below the build plate surface on trigger which can not happen if your bltouch has a positive offset on the mount.

Before moving on, verify that the BL-Touch is mounted at the correct height, the pin should be roughly 2 mm above the nozzle when retracted

Because there is so many clones and variation of the BLTOUCH maybe the best idea if possible is to identify what you have and who made it and see that manufactures documentation on the correct mount height of the version of clone bltouch ie if it is a microprobe from BTT then look there as a example as they give recommendations on deployed

Microprobe
Microprobe2001×1185 167 KB