Mizar-S nozzle as BLTouch

Basic Information:

Printer Model: Geeetech Mizar-S
MCU / Printerboard: Proprietary Geeetech’s board GTM32_LCD35_A10 - STM32F103VET6 controller
Host / SBC: Orange Pi zero3
klippy (1).log (270.4 KB)

Hello Klipper community!

I’m struggling to configure my Geeetech Mizar-S printer with Klipper. The printer uses the nozzle itself as a probe, which works flawlessly with the stock Marlin firmware. But with Klipper, things get messy.

The Problem:

The “official” geeetech’s config uses [bltouch] with x/y/z_offset: 0 (since the nozzle is the probe). During PROBE_CALIBRATE, Klipper calculates a negative z_offset, which it rejects. Even with a loaded bed mesh, the nozzle scrapes the bed if I leave z_offset at 0. The probe does trigger correctly during manual tests, so the hardware works. (I tested it using tests described in the BL-Touch article on klipper’s website) And I understand the reasons for negative z_offset and it’s ok, there gotta be another way? :slight_smile:

What I’ve Tried:

  • Checked the Marlin firmware sources: The probe uses a BLTouch-like protocol where Marlin sends servo angles to SERVO0 (e.g., to activate/stow the probe) - it is control_pin in klipper’s config.

  • The printer’s proprietary printhead board seems to translate these angles into probe actions.

  • Found similar setups (like the Anycubic Vyper) that use [probe] with custom activate_gcode instead of [bltouch] and I think it might be a solution with the right gcode :slight_smile:

My Questions:

  1. Config Approach:

    • I Found a [servo] and SET_SERVO commands in klipper’s G-Code references. Can I replace [bltouch] with [probe] and use activate_gcode to mimic Marlin’s servo commands? For example:
       [probe]  
       pin: ...  
       activate_gcode:  
           SET_SERVO SERVO=my_servo ANGLE=...  ; Lower probe  
       deactivate_gcode:  
           SET_SERVO SERVO=my_servo ANGLE=...  ; Raise probe  
    
    • Can I map Marlin’s BLTouch servo angles to Klipper’s SET_SERVO values?
  2. Safety concerns

    • If I define [servo] in printer.cfg and use SET_SERVO in activate_gcode, could incorrect angles crash the nozzle into the bed or make some other damage? Could it be made relatively safe?

Context:

Any advice or examples would save my sanity. Thank you all!

Hi everyone!

I’d like to share my experience in configuring the probe on a Mizar-S printer using Klipper. Although the Mizar-S isn’t widely popular and even is no longer listed in Geeetech’s shop, I hope this might be useful to someone.

When I was working with a multi-million-dollar laser cutter, my supervisor advised me to learn by «pushing buttons». I applied the same approach here.

Key Findings

  1. The SET_SERVO macro accepts angles in degrees — there’s no need to convert them from “Marlin’s angles” I mentioned. I was initially confused by the bltouch.py file imeplementation.
  2. Experimenting with a simple servo didn’t work at first, but I figured out that the issue was with the minimum_pulse_width and maximum_pulse_width settings in the [servo] section.

Configuration Steps

I set the following parameters for the servo, based on what I found online for BLTouch:

[servo z_probe]
pin: PA8
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024

Don’t know how would you normally determine these parameters, but I hoped that if printer emulates bltouch - the values for bltouch would work and they did :slight_smile:

After making these changes, the board in the printer toolhead started to recognise my SET_SERVO commands: turn LED on/off, activate/deactivate probing sensor. I had to implement these commands using [gcode_macro] .

Current Configuration

Here’s my current Klipper configuration for the servo and macroses:

[servo z_probe]
pin: PA8
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024

[probe]
pin: ^PC4
z_offset: 0
samples: 2
activate_gcode: start_probe
deactivate_gcode: end_probe

[gcode_macro start_probe]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=10
  G4 P750

[gcode_macro end_probe]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=50
  G4 P750

[gcode_macro reset_probe]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=150
  G4 P500

[gcode_macro white_led]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=90
  G4 P150

[gcode_macro color_led]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=70
  G4 P500

[gcode_macro no_led]
gcode:
  SET_SERVO SERVO=z_probe ANGLE=30
  G4 P500

All angles and delays were taken from the Marlin firmware version.

Results

With this setup, I can now use PROBE , PROBE_CALIBRATE , and PROBE_ACCURACY .

However, PROBE_ACCURACY yields inconsistent results unless I perform the “sensor calibration” procedure.

In Marlin, this printer requires you to lightly push the nozzle upwards before the autoleveling procedure. Based on the source code, it sends a signal to toggle a “5W mode” and waits for the probe to trigger. After that, it lights up the white LED (probably storing some calibration data).

Probe Accuracy Results

  • Before sensor calibration:
probe accuracy results:
maximum: 0.099000
minimum: 0.049000
range: 0.050000
average: 0.086750
median: 0.091500
standard deviation: 0.013668
  • After sensor calibration:
probe accuracy results:
maximum: 0.101500
minimum: 0.094000
range: 0.007500
average: 0.099000
median: 0.099000
standard deviation: 0.001936

Next Steps

Now I need to create a macro that mimics the behaviour of sensor calibration. I think I can achieve this with [delayed_gcode] . The idea is to poll the Z probe state periodically until it triggers.

Question

Does anyone know when it’s correct to reset the BLTouch? I didn’t find its usage in the customised Marlin firmware, except for the original parts that work with BLTouch. I’m wondering if it would be appropriate to call reset in deactivate_gcode or activate_gcode - just in case!

Looking forward to your insights and feedback, thanks!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.