Add sensorless homing configurations

[kyleisah]

I've made some really nice sensorless homing configurations, as well as some minor grammar fixes in klicky-probe.cfg.

What's new?

• there is now a klicky-sensorless-homing.cfg file that can be included using klicky-probe.cfg to easily enable/disable these features.
• There are 3 macros added when using these configurations. 1 is simply a variables macro to keep variables in one nice spot and serve as a "do not edit below this line" kind of thing. The other 2 are reworks and improvement's of @clee's sensorless homing macros shared on the Voron Docs site. The basis of the reworks are some minor corrections to order of operations, easier configurability, and minimal driver current change redundancy.
• Driver current will only be set to homing_current when the opposite axis is not homed. This helps to minimize tmc current messages in the console. If XY is not homed, and you home X or Y, homing_current will be used until both X and Y axes are homed, and then the current will return to default before attaching/docking the probe or homing Z.
• Framework for this to work has already been laid out before if you had _HOME_X or _HOME_Y macros defined, so changes are not necessary, as we are using this existing framework for these macros.
• Homing individual axes still works just fine
• "backoff" move distances are easily adjusted in the klicky_variables config
• "backoff" moves will use the homing_speed defined for each axis in printer.cfg for consistency
• "Home Y Axis First" will need confirmation if it works correctly, but I'm pretty sure it does. The backoff distances in the current klicky-probe-variables.cfg are overwritten when using klicky-sensorless-homing, so no worries there.

[pasha4ur]

Hello

Where can we download "klicky-sensorless-homing.cfg"?

I found here https://github.com/jlas1/Klicky-Probe/blob/9bfb6ca82c73355d8a165603620ef02984970d87/Klipper_macros/klicky-sensorless-homing.cfg

This should be added to main folder bcs stock Klicky probe bad code can destroy printers.

[kyleisah]

Bad code in general can destroy printers. I've had this PR sitting for a long time. I don't think jlas wants to integrate it the way I have it, so it's kind of just sat. I've got a sensorless homing suite of macros that works okay, but I am still working on finishing it.

[jlas1]

Need to take another look at this

[kyleisah]

Need to take another look at this

I've been using these macros on my salad fork for a while now, and I've only just discovered that there are some confilcts that happen somewhere within the klicky macros. Sometimes the bed will z_hop for homing twice and I've got no clue why lol. Over all, it works, but there's some quirks that I just can't figure out due to the complexity of Klicky's config.

[kyleisah]

I should say, I'm actually working on the whole sensorless thing right now since it came up, and I'm getting close to something I'm happy with.

[kyleisah]

So this might not need to be merged anyway, since you were more interested in it being standalone and not a part of klicky.

[kyleisah]

@jlas1 if you're at all curious, here's the (mostly) finished macro. Not a lot left to polish. But maybe you'll find something here that would help you out.

https://github.com/kyleisah/EZ-Sensorless-Homing/tree/main

[kyleisah]

Something I caught just by taking a look, that has bit me with my standalone version was this: If the user is not using TMC2209 drivers, they're gonna have errors. Might have to have some kind of if/else check to define the drivers correctly for adjusting homing/run current

[kyleisah]

Something like this might work:

{% if printer.configfile.settings['tmc2209 stepper_x'] is defined %}
  {% set default_x_run = printer.configfile.settings['tmc2209 stepper_x'].run_current|float %}
{% endif %}

{% if printer.configfile.settings['tmc2209 stepper_y'] is defined %}
  {% set default_y_run = printer.configfile.settings['tmc2209 stepper_y'].run_current|float %}
{% endif %}

{% if printer.configfile.settings['tmc5160 stepper_x'] is defined %}
  {% set default_x_run = printer.configfile.settings['tmc5160 stepper_x'].run_current|float %}
{% endif %}

{% if printer.configfile.settings['tmc5160 stepper_y'] is defined %}
  {% set default_y_run = printer.configfile.settings['tmc5160 stepper_y'].run_current|float %}
{% endif %}

There might be an easier way to check the driver types defined and go from there, but this is what I came up with for now. :)

[pasha4ur]

Bad code in general can destroy printers. I've had this PR sitting for a long time. I don't think jlas wants to integrate it the way I have it, so it's kind of just sat. I've got a sensorless homing suite of macros that works okay, but I am still working on finishing it.

Klicky destroyed 2 printheads on my printer. Because I used Home X after printing ends.

Klicky moves Z before homing X and destroys printheads through collisions with printed objects.

[jlas1]

That's very strange, klicky should not move the toolhead down? Any specific on your setup?

On Thu, 28 Sept 2023, 07:26 Pavel, @.***> wrote:

Bad code in general can destroy printers. I've had this PR sitting for a long time. I don't think jlas wants to integrate it the way I have it, so it's kind of just sat. I've got a sensorless homing suite of macros that works okay, but I am still working on finishing it.

Klicky destroyed 2 printheads on my printer. Because I used Home X after printing ends.

Klicky moves Z before homing X and destroys printheads through collisions with printed objects.

— Reply to this email directly, view it on GitHub https://github.com/jlas1/Klicky-Probe/pull/181#issuecomment-1738541998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7HHCUEEFAISCAGQS52CF3X4UKCTANCNFSM6AAAAAAUK2PS34 . You are receiving this because you were assigned.Message ID: @.***>

[pasha4ur]

That's very strange, klicky should not move the toolhead down? Any specific on your setup?

Klicky macroses always move Z to safe Z distnace when you make homing X or Y.

If you have printed details with height more then safe Z under nozzle and call G28 X in after print gcode Klicky macroses will break printhead.

As I said 2 printheads were broken after Klicky installation before we found reason.

[kyleisah]

I've got the configuration totally mint for sensorless homing and klicky probe now. 😄

I only have one concern though. The homing_current stuff right now assumes the printer is CoreXY. A check can be added using {% set kinematics = printer.configfile.config.printer.kinematics %} or something like that. Depending on the kinematic type the correct stepper's current might need to be changed. Klicky is pretty universal, so this may need to be monitored. I don't know how klipper handles all this stuff under the hood.

[kyleisah]

@jlas1 have you gotten a chance to try this yet? Works really well on my machine.

[karlfife]

I think a G400 needs to be added to the top of the x_home, and y_home sections of homing_override in klicky_macros.cfg. This is in service of sensorless homing. X homes fine, Y homes fine, but if they run back-to-back in a single home-all macro, the opposing axis will always already be triggered from the previous virtual end-stop trigger (i.e. The same AB motors for both endstops). This was essential (for me) to make it work. Using TMC2209 steppers, and a BTT Octopus 1.1 board e.g.

        # Home y
        {% if home_y %}
++          M400  # Wait for command completion.  Prevents false virtual endstop triggers when sensorless homing. 
            {% if override_homing == 'Y' %}

[kyleisah]

I think a G400 needs to be added to the top of the x_home, and y_home sections of homing_override in klicky_macros.cfg. This is in service of sensorless homing. X homes fine, Y homes fine, but if they run back-to-back in a single home-all macro, the opposing axis will always already be triggered from the previous virtual end-stop trigger (i.e. The same AB motors for both endstops). This was essential (for me) to make it work. Using TMC2209 steppers, and a BTT Octopus 1.1 board e.g.

        # Home y
        {% if home_y %}
++          M400  # Wait for command completion.  Prevents false virtual endstop triggers when sensorless homing. 
            {% if override_homing == 'Y' %}

Pretty sure I’ve tried this before but I could be mistaken. What did you have clear_time set to? The clear_time param is for allowing the stallguard registers to clear, and as far as I know, that’s why M400 doesn’t always work, because commands can clear from the buffer before the TMC registers have had enough time to clear.

[karlfife]

I'm sorry, but I'm not familiar with the clear_time parameter.

Poking around, I don't see any reference to it grepping in /printer_data/config or /klipper. FWIW, both the host and the MCU are running Klipper v0.12.0-54-g6f686dde.

Poking around online, I don't see reference to it in the context of stallguard, klipper, klicky, or gcode.

Whatever the optimal fix turns out to be, I'm happy to also test it against some new TMC2240 drivers I've got here to play with for A/B. :-)

[karlfife]

With regard to time, I had tried various wait states in the same place in the code, i.e. a good old-fasioned G4 [xxxx] for various durations including an eternity, 6000. These waits were not a fix (ever if memory serves). So far I've not seen the issue when using the M400 after many dozens of iterations, including in Klipper FW v.11.