Problems with sensorless homing on MKS Nano v3.1

General Discussion
1

Basic Information:

Printer Model: Voron Switchwire
MCU / Printerboard: stm32f407 / MKS Robin Nano v3.1
Host / SBC: Linux Mint
klippy.log.zip (5.3 KB)

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 trying my luck here to solve my problem with sensorless homing on MKS nano v3.1 under Klipper.
I’ve tried everything to get sensorless homing to work on my x-axis but without success or only halfway.
My printer is a Voron Switchwire and works perfectly with basic homing microswitches.

Let’s start with the basics, my stepper_x:

[stepper_x]
step_pin: PE3
dir_pin: PE2
enable_pin: !PE4
rotation_distance: 40
full_steps_per_rotation: 200
microsteps: 32
endstop_pin: tmc2209_stepper_x:virtual_endstop 
homing_retract_dist: 2 
position_endstop: 0
position_min: 0
position_max: 200
homing_speed: 40
#homing_positive_dir: false

[tmc2209 stepper_x]
uart_pin: PD5
run_current: 0.8
hold_current: 0.5
interpolate: True
stealthchop_threshold: 999999
sense_resistor: 0.11
diag_pin: !PA15
driver_sgthrs: 10

Then I activated diag_pin: in PA15 and I’m in UART mode on TMC 2209, so it should work.

DUMP_TMC STEPPER=stepper_x sends me the right information indicating that my stepper takes UART mode into account and yet, when I run an x-homing, the axis doesn’t move.
I’ve played with driver_sgthrs and homing_speed to no avail.

What’s strange is that under Mainsail, when I run homing, it seems to take place since the button turns blue and I can then move the axis positively but not negatively beyond the homing point without getting an error message indicating that the minimum limit has been exceeded, which indicates that homing has been taken into account. However, the axis didn’t move all the way to the mechanical stop.

Disabling homing_positive_dir has no effect and setting it to “true” returns an error.
I’ve tried increasing the power supply to run_current: 1.0 but to no avail.
Before homing QUERY_ENDSTOPS tells me that x is Triggered when it should be Open.
Since QUERY_ENDSTOPS always returns “Triggered”, this means that Klipper is always reading a HIGH or LOW state on PA15, no matter what. So I disabled PA15 by removing the jumper to see if I got an error but no error in Klipper, it’s like it doesn’t care about diag_pin.
Then I thought that if the PA15 didn’t seem to be taken into account, maybe it was read backwards, so I sent it back with a !PA15.
A QUERY_ENDSTOPS now tells me that the endstop_x is Open, which is a good sign.

I launch an x-homing, and miraculously the motor goes in the right direction for a homing, but takes a long time to stop, jumping violently from step to step.
Klipper tells me that x hasn’t reached its homing and QUERY_ENDSTOPS returns endstop_x: Open when it should be Triggered.

I’ve tried turning down driver_sgthrs and stealthchop_threshold: 999999 to the maximum, but nothing works, the homing is still as violent as ever, but without being taken into account.

I’ve adapted and added mykepredko’s macro to reduce the current on motor x when homing but it doesn’t seem to have any effect, the motor still retains as much power when homing.

I can’t take it anymore, and I wonder if sensorless homing is possible on this card after all.
Sorry for the length of the post, but it’ll save us all a lot of time if I don’t get suggestions I’ve already tried out.:wink:

2

IIRC, diag pin should look like that:
diag1_pin = ^PA15, not like diag_pin = !PA15

I would suggest that you check the guide:

Hope that helps.

Btw, klipper will switch 2209 to StealthChop while homing, regardless of your config.
Just because it is the only way to use StallGuard4 on this driver.

1 Like
3

So yes, the addition of the ^ allows you to finally have an open endstop before the homing, but I have to keep the ! otherwise the axle just makes a slight “Tac” and doesn’t move at all in the direction of the homing.

But this doesn’t solve the problem, because with the “correct” diag_pin configuration: ^!PA15, when I launch the homing, the axle moves to the stop, but once it’s there it continues to bang hard against it, forcing me to make a quick M112 to stop it, and when I check the QUERY_ENDSTOPS, x is still Open and not Triggered.

I consulted Klipper’s documentation on sensorless homing, but was unable to obtain correct homing.

I’ve added the macro [gcode_macro SENSORLESS_HOME_X] to limit the tension on the motor during homing but I can’t see any change in the motor force during homing because I don’t know how to call it from homing_override config section or from a START_PRINT macro for it to take effect.

I’ve also tested the driver_SGTHRS setting, starting from 255 and going down by 10 each time, with no observable result on the brutality of the homing once the stop is reached.

4

Well, you may want to look here: TMC Coolstep and how to make it works
And here: klippy: add stallguard monitoring tool by nefelim4ag · Pull Request #6592 · Klipper3d/klipper · GitHub

General recommendations will sound like:

  • You want to know the datasheet of the motor.
  • You want to use the appropriate current for the motor.
  • You want to use an appropriate speed for the motor, like high current and low inductance motors, generally should work with homing speed ~60mm/s

You will not be able to query endstop, because diag will only work during homing and for a very short duration, around 1-4 full steps.

Probably, if you seen “Tac”, without ! that sounds like too high sensitivity.
According to the documentation, stated above, it sounds like TMC2209 should work without inversion.

Hope that helps.

5

Wow, we’re getting into things that are way too complicated for me. Graphics and I aren’t really buddies, if you know what I mean, so if we could keep it simple. Is it possible to make this sensorless homing work on my x-axis, simply and without going into programming lessons and immeasurable mathematical formulae? If not, I’ll plug my good old micro switch back in and forget all about this sensorless homing, which will be nothing more than a pipe dream.

In the meantime, what I can’t understand is that when I delete the ! my endstop x switches to Triggered without having homed.

And if, as you say, the “Tac” I’m hearing means that the axis is too sensitive, this would imply that homing has been carried out, which is what Mainsail is showing me, since the button turns blue, but the QUERY_ENDSTOPS then tells me x:TRIGGERED y:open z:open which is not normal.

6

The settings are wrong and incomplete in multiple places. All the missing pieces are in the documentation. Please closely read and follow the instructions here: TMC drivers - Klipper documentation

7

I consulted all the documentation concerning sensorless homing on klipper and on Voron, and adapted my printer.cfg accordingly:

[stepper_x]
step_pin: PE3
dir_pin: PE2
enable_pin: !PE4
rotation_distance: 40
full_steps_per_rotation: 200
microsteps: 32
endstop_pin: tmc2209_stepper_x:virtual_endstop 
homing_retract_dist: 0 
position_endstop: 0
position_min: 0
position_max: 200
homing_speed: 20
homing_positive_dir: false

[tmc2209 stepper_x]
uart_pin: PD5
diag_pin: ^PA15
run_current: 0.8
#hold_current: 0.5
interpolate: false
stealthchop_threshold: 0
sense_resistor: 0.11
driver_sgthrs: 60 # 255 the more sensitive, 0 the least sensitive

[gcode_macro SENSORLESS_HOME_X]
gcode:
    {% set HOME_CUR = 0.700 %}
    {% set driver_config = printer.configfile.settings['tmc2209 stepper_x'] %}
    {% set RUN_CUR = driver_config.run_current %}
    # Set current for sensorless homing
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CUR}
    # Pause to ensure driver stall flag is clear
    G4 P2000
    # Home
    G28 X0
    # Move away
    G90
    G1 X5 F1200
    # Set current during print
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CUR}

I consulted all the documentation concerning sensorless homing on klipper and on Voron, and adapted my printer.cfg accordingly:
But there’s nothing I can do, the axis makes a slight jerk but doesn’t move in the direction of the stop. I even have the impression that it’s doing it in the wrong direction.
I tested with the command SET_TMC_FIELD STEPPER=stepper_x FIELD=SGTHRS VALUE=50
Starting from 255 and going down 10 by 10 until 0 with always the same result.

So either there’s something I’m missing and in that case, instead of telling me that something isn’t right in my printer.cfg or referring me to info pages, please point me in the right direction because I’m on the verge of putting my micro switch back on and dropping the sensorless homing.

I can’t take it anymore, I’ve been fighting for two days without getting anything concrete and I’d really like to make progress on this printer.

8

While I understand your frustration, please avoid venting it here. You came here asking for help, and you could have followed the proper instructions beforehand. It doesn’t make any sense to search for a deeper cause when the basics are already off.

Post a fresh klippy.log showing the issue.

9

Don’t worry, I’m not the type to wait for everything to fall into my lap. I built my printer myself from start to finish and generally prefer to solve my problems on my own as much as possible. But sometimes, if you keep looking into things, you end up no longer seeing the obvious, hence my request for help.

But I won’t bother you any longer, I’ve understood the spirit of the community here and it’s not what I expected.

That said, thank you for taking the time to reply.

10

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