Open kyleisah opened 1 year ago
Hello
Where can we download "klicky-sensorless-homing.cfg"?
This should be added to main folder bcs stock Klicky probe bad code can destroy printers.
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.
Need to take another look at this
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.
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.
So this might not need to be merged anyway, since you were more interested in it being standalone and not a part of klicky.
@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.
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
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. :)
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.
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: @.***>
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.
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.
@jlas1 have you gotten a chance to try this yet? Works really well on my machine.
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' %}
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.
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. :-)
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.
I've made some really nice sensorless homing configurations, as well as some minor grammar fixes in klicky-probe.cfg.
What's new?
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._HOME_X
or_HOME_Y
macros defined, so changes are not necessary, as we are using this existing framework for these macros.printer.cfg
for consistency