Physical Z endstop and dockable Z probe - meshing questions

Basic Information:

Printer Model: Tronxy X5SA Pro 330
MCU / Printerboard: Factory F446
Host / SBC: Pi 3B 1GB
klippy.log: unimportant

Describe your issue:

Hello,

I’ve a printer that has a physical Z endstop along with a dockable probe. Running bed meshing after homing the printer results in a bed mesh that sits at a Z level different than zero (understandably as the probe itself is around 8mm taller than the nozzle).

Question is - is there a way to make Klipper account for this? The workflow in my head would be:

  • Zero the bed (which also by how I designed this, also zeroes the nozzle)
  • Attach the probe and measure its height relative to the endstop
  • Mesh the bed, subtracting the probe relative height from the value
  • Store that mesh as a true nozzle mesh.

Instead, by current Klipper probe workflow, setting the probe Z offset as a probe-to-nozzle distance means it prints mid air, which makes perfect sense in a printer where the probe is permanently mounted higher than the nozzle, but not in the case of a detachable probe.

How would I go about configuring Klipper for this particular case?

At the moment all I do is use the meshing procedure to see how far off from square the bed is, then adjust the screws accordingly. At no point I load the mesh, which is not really how it’s meant to be used I imagine!

Thank you in advance.

Hello @SGM !

Have you tried with another G28 Z after the bed mesh ?

I have a Z endstop on voron 0.2-ish at max Z and a slideswipe detachable probe for bedmesh and seting the nozzle offset.

How do you know the bed mesh is at offset? I have :

[probe]
x_offset: 0
y_offset: 0
z_offset: 15.02 

and BED_MESH_MAP reports values around 0:

mesh_map_output {"mesh_min": [2.0, 2.0], "mesh_max": [112.96, 112.96000000000001], "z_positions": [[-0.060601, -0.021435, -0.019351, -0.015601, 0.008982, 0.038565, 0.021482, 0.022732, 0.028982], [-0.026435, -0.016851, 0.021482, 0.018982, 0.026482, 0.033982, 0.048982, 0.013149, 0.04564
.....

The printer has a small but significant variation between endstop derived Z position and probe derived Z position due to thermal drift and whatnot that is cancelled out by applying a gcode offset for Z based on a separate probe measurement. It turns out that while the probe is quite repeatable within one attachment cycle, there is some variability from probe attachment to attachment, so probe offset is done in several measurement rounds with attach and detach between.

See https://github.com/bozzzzo/voron_v0_printer_config/blob/master/slideswipe.cfg
Z offset machinery entry point is at SS_RESET_Z_RELATIVE_TO_PROBE which is called from PRINT_START right after bed mesh

1 Like

Yep - my start-print macro always does a G28 prior to the purge line.

@bozzo Because my bed mesh looks like this:

#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  8.710000, 8.688750, 8.727500, 8.786250
#*# 	  8.566250, 8.603750, 8.597500, 8.600000
#*# 	  8.545000, 8.618750, 8.575000, 8.528750
#*# 	  8.765000, 8.787500, 8.756250, 8.595000

FWIW - I can’t access the file you posted, throws a 404.

Thank you both!

haha, publishing links to private repositories…. it’s public now

1 Like

…good one :wink:

Thank you @bozzo , I’ve been having a look while I set up some new bits in the machine, but I still have some reading to do. My probing procedure is inifinitely simpler and inherently less robust:

gcode_macro ABL]
gcode:

    M104 S150 ; Heat up hot end before bed calibration
    ; Move to the right of the clicky sensor location , lower a bit, get inline with it on Y, go down until the magnets pull, then raise up.
    G0 X50
    G0 Z10 Y310
    G0 X12
    G1 Z5
    G1 Z50
    G0 X50

    BED_MESH_CALIBRATE ; do the pokey probe thing, stores to default profile

    ; Do the same as before, but backwards. First raise Z to avoid collisions, align on Y, get to its right, align on X, lower the probe in to the stowage, then move away from it.
    G0 Z30
    G0 Y310
    G0 X50
    G0 X12
    G0 Z5
    G0 X50
    G0 Z20

I wonder if simply setting SET_GCODE_OFFSET Z to match the probe offset after loading the mesh would do it.

Obviously the mes would be as good as unreadable given it’s not centered around 0, but it would print at the right height (unless the slicer uses that command for something else…)

I can probably also write a new mesh with the values derived from the initial probe Z calculations, load that mesh in and it should, in theory, print properly?

@SGM what is your z axis config? maybe klippy log is needed anyway.

maye this is causing issues? higher than nozzle is negative Z territory. Z measures distance from nozzle to bed, regardless of bed or nozzle moving in Z. so detachable probe z is always between nozzle and bed and so always positive…

Going to guess you mean printer.cfg:

[stepper_z]
step_pin: PA6
dir_pin: PF15
enable_pin: !PA5
microsteps: 16
rotation_distance: 4
endstop_pin: !PC13
position_endstop: 0.2
position_max: 400
position_min: -2

[probe]
x_offset: -40
y_offset: -10
pin: !PE3
speed: 10

Physically speaking it’s a dual Z stepper/lead screw with tied drivers (so they move together). There’s a Z endstop used to zero the bed, which is set at somewhere around 0,2mm nozzle-bed distance. The bed probe itself is a detachable magnetic microswitch.

Your point makes sense - but I’d be surprised if klipper didn’t account for the possibility of a probe being between the bed and the nozzle, not the nozzle and the carriage. In effect I’m using a deployable probe (BLTouch style) but instead of deploying it you need to attach it. Granted I use none of the BLTouch macros.

Where is your [probe] z_offset ???

Value is Z position at which probe triggers when bed is located correctly relative to nozzle.

I’m a complete idiot!

Of course it isn’t going to work without a valid Z-offset. How else is the mesh going to know what’s its reference point?

Setting the Z-offset to the valid distance instead of zero fixed the meshing and the mid-air printing. Thanks for that!

1 Like