Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
After homing for x direction it goes in y roughly without stopping. klippy.log (7.2 MB)
First off, you’re not loading the basic Mainsail operations macros using the following statement at the start of your printer.cfg:
[include mainsail.cfg]
This won’t affect your current issue, but it will be a problem after you get it resolved.
Now, you’re not terribly descriptive in what your problem actually is.
Is your Y axis moving in the correct direction? (ie toward the rear of the printer)
What does it do when it reaches the end? I would expect it to stop and shudder with the two steppers vibrating because the gantry has reached the endpoint - is this correct?
If what I’ve described above is correct, then you need to adjust the driver_sgthrs for [tmc2209 stepper_y] until it’s recognized. I’m not sure where you got the value of “150”, I guess it works for you for X but you can’t expect it to work for “Y”.
I would suggest start lowering it and the most efficient way is to use a binary search approach - decrease by half and determine whether or not you still have a problem at which case you decrease again by a quarter or add a quarter. Continue you this until you have a range of 5-10 and then pick the lower value.
The recommended way of doing homing on a CoreXY is to use a macro like:
[gcode_macro global] ### Global Variables
variable_xy_run_current: 0.8
variable_xy_home_current: 0.6
gcode:
#### Macros to implement sensorless homing
[gcode_macro _HOME_X]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
G4 P500 # Wait for StallGuard registers to clear
G28 X
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91 # Move away to centre of build surface
G1 X125 F1200 # Changed for Micro Swiss NG
[gcode_macro _HOME_Y]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
G4 P500 # Wait for StallGuard registers to clear
G28 Y
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91 # Move away to centre of build surface
G1 Y-140 F1200 # Changed for Micro Swiss NG
[homing_override]
axes: xyz
gcode:
{% set home_all = 'X' not in params and 'Y' not in params and 'Z' not in params %}
{% if home_all or 'X' in params %}
_HOME_X
{% endif %}
{% if home_all or 'Y' in params %}
_HOME_Y
{% endif %}
{% if home_all or 'Z' in params %}
G28 Z
QUAD_GANTRY_LEVEL # Added 2023.07.11
G1 Z10
{% endif %}
This will allow you to adjust the current (which determines the torque put out by the steppers) - you’ll see that I reduce the current for homing as well as put in a delay (this is G4) to allow the TMC2209’s to prepare for the homing movement.
I’ve tried different values of SGTHRS and the toolhead keeps pushing the limit. Another question is that there is no way to override the general G28 gcode . Even I delete the macro and including the general homing_override it does the same for individual homing
I have literally just done my identical machine changeover to sensorless as well, and my values are as follows, hope it helps.
V2.4, Octopus V1.0 , TMC2209
Home current: 0.59 on both
SGTHRS 150 on both.
Admittedly the Y axis is thumping slightly harder then the X axis, but I left it for now to be equall both directions.
Also what I found and thought was strange is that by doing an individual axis manually from the dashboard, it would work correctly, but later on when I did the HOME_ALL from the dashboard it did not!
I had to go back to the adjustments and fine tune it further.
I have honestly no idea why it would be different doing an axis on its own or in tandem with HOME_ALL?
I hope the OP gives more accurate feedback and description of the problem.
Taking in consideration the macros given from @mykepredko and the values SGTHRS from @3dcase I have still the same result . None of them stop and keeps pushing the limit
My first experience with sensorless homing was with reduced motor currents too.
But for the back EMF you need enough speed or current to get a stall detected properly.
I later used the normal run current but higher homing speeds (at least on my Voron v0).
That worked far better than before. It now homes with 100 mm/s and the sound when hitting the frame is just a single clack…
Compared the the Micron+ with TMC5160 the TMC2209 are easier to set up in my opinion.
However every printer is special and needs its own treatment and setup.
So keep on testing and use whats best for your printer.
Which instructions did you follow to set this up. Please post a link?
If the motors do not stop at all, it sounds like some jumpers are not in the right place and the system is expecting a switch stat change.
Have you removed the connectors that were on the limit switches? Or did you not have this running with limit switches before?
Did you fit the jumpers under the stepper drivers correctly as per instructions from Voron?
Did you install the diag jumpers in their correct sockets correlating to the steppers that are for X and Y?
Please show us your setup guide and a photo of the jumpers?
At the very least, you have to experiment with the SGTHRS values to find ones that work with your printer. Along with that, you may have to change the variable_xy_home_current (from my macro above).
It takes a bit of time, usually less than an hour but you should be able to get there.
Each printer is different and there’s no one size fits all.
It works fine now (Octopus btt pro , tmc2209 ). Thanks @mykepredko@LifeOfBrian@3dcase . I got to the same value home_current 0.59 and sgthrs 150 . I also use the macro from @mykepredko . www.klipper3d.org needs to update this guide for corexy . I didn’t include mainsail.cfg btw .
@mykepredko@LifeOfBrian
I have a question about stability over time with regards to this sensorless homing.
Do these values need evaluating after let’s say a year? We all know that electronics have wear and resistance can change over use. I would, with my limited knowledge of real electronics, kind of expect that this could go horribly wrong one day when you start a print.
Or is this not the case? Is my worry unrealistic?
I would appreciate an answer with for instance how long it has been in use with somebody, without having gone wrong.
I think, you are at least not wrong!
However I do not see the problem primarily with the electronics but with the mechanical parts of the printer.
They should wear faster than the electronical components involved here.
Settling dust on the rails, worn out belts, no or insufficient grease on the moving parts and so on will alter the parameters that had been used to determine the current stall guard thresholds.
When those parameters change the behavior of the sensorless homing will change too.
One day during the homing sequence the stop signal might be triggered mid way resulting in wrong reference coordinates for the print.
The rest is up to you imagination.
So I would not suggest having the printer unsupervised all the time and regularly check the reliability of the sensorless homing sequence. And of course: doing regular maintenance on your printer!
In contrast a mechanical endstop switch can fail as well. And depending on its logic (NC/NO) it can cause serious failures too.
Maybe one day we have AI support via an internal camera that validates the homing success with optical recognition and reports back a false homing procedure.
I might consider going with mechanical endstops on my Micron again but maybe not…
Brian has answered the question in terms of wear nicely, the only thing that I would add to that is that your printer will fail mechanically before the sensorless homing electronics does.
Actually, if the driver chip degrades to the point where sensorless homing doesn’t work, the stepper driver functionality will have died as well.
I’m running sensorless homing on all six of my printers (1x Voron 2.4, 3 custom CoreXY, a resurrected Sapphire Pro and a custom bedslinger). The custom CoreXY printers have been running for 2 years plus, the Voron for about a year and a half, the Sapphire Pro for a year and the bedslinger for six months.
In that time, it’s been about 5,000 hours of operation without any homing failures.
Ok, I shall not worry anymore about electronic degradation. The point about mechanical failure, and how to minimise stress on the sytem by doing proper maintenance, I can fully agree with and validate as a machine engineer.
So I will clean my rails and lube them periodically as to keep things happy.
Thanks guys, I love this sensorless homing even more now.
