Printer Model: Twotrees SP5
MCU / Printerboard: MKS Robin Nano V3
Host / SBC: BTT Pad 7
klippy.log: NA
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:
I’m converting my SP5 to Klipper and need to use sensorless homing for X&Y. I think I have everything correct, I’ve checked the pin #'s, but would appreciate feedback so I don’t break anything when I fire it up.
First, are you sure you need your run_current so high? I would think you’d want to be around 0.7A to 0.8A for normal operations.
Secondly, when you’re running with Sensorless homing, I’d recommend running with the lowest possible current. I use the following macros to set the homing current and then return it to a run current level:
[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 %}
Finally, you’re going to have to experiment with your homing current values and driver_sgthrs value for each axis. I recommend setting as low a home_current as moves the gantry/bed reliably. Next, start at a fairly high driver_sgthrs value and work your way down.
The current settings were from a config on Github and I figured they might need to be changed. So I assume you need to use the macro(s) instead of the usual homing? It’s been a while since I’ve messed with Klipper for my Ender 3. This is a bit more complicated. Thanks
You don’t need to use the macros but they give you control over the current/speed of the homing as well as where the toolhead is when they’re finished. Having one place to set the current values means that you don’t have to search through your printer.cfg to change everything individually (and maybe miss something).
Sorry, I grabbed the macro from one of my running printers with the QUAD_GANTRY_LEVEL capability - you can delete this line from the macro.
On a printer like the Voron 2.4 where there is the ability to tilt the bed to ensure it’s in plane with the toolhead X/Y movement, QUAD_GANTRY_LEVEL moves the corners up and down, where appropriate.
I messed with this for a couple hours yesterday. X homes perfectly with SGTHRS set @ 100 . Y however would move 1-2mm, trigger and showed it was at 300 regardless of where it was. I adjusted it down in increments of 5 until it homed properly, once. After that it would continue trying to move after it hit the end stop and had to be shutdown. I increased SGTHRS in increments of 1 until it would again trigger prematurely. Never could get it to home properly.
I should have made a note of the numbers but it was getting late and my brain was starting shutdown mode. Could the inertia of the Y carriage be causing a current surge that’s triggering the stepper prematurely?
The first situation you are getting on the Y axis is you have the sensitivity set too high.
Homing in increments of 1 is going to be a problem and will drive you nuts as you don’t get a good idea of where your value is in in terms of being centred between the situation where the gantry will just sit there or it will move to the endstop and shudder.
The goal is to find a good intermediate value that is as far away from these two extremes as possible.
Trying to write it out as an algorithm, what I do is basically a binary search to first find a point where things work and then find the limits where it doesn’t and then set SGTHRS to the mean between them:
Start at the halfway point
set SGTHRS = 128
set incVar = 64
Will need to adjust Motor Current if any of these situations is encountered
if SGTHRS >= 240 then current too low. Increase motor current by 0.1A/set SGTHRS = 128/set incVar = 64/goto 3.
if SGTHRS <= 16 then current is too high. Decrease motor current by 0.1A/set SGTHRS = 128/set incVar = 64/goto 3.
Run homing on the axis.
set incVar = incVar / 2
a) If the Gantry just stops then you are too sensitive: set SGTHRS = SGTHRS - incVar/goto 2.
b) If the Gantry moves to the end of the track and the motor(s) chug against the stop, then you are not sensitive enough: set SGTHRS = SGTHRS + incVar/goto 2.
c) If the Gantry moves to the endstop without any chugging then go to 4.
Have SGTHRS value that provides sensorless homing BUT maybe on the edge - want mean value in rage of gantry stops when homing starts and gantry chugs at endstop
set tempSGTHRS = SGTHRS/set highSGTHRS = SGTHRS
set highSGTHRS = highSGTHRS + incVar
Run homing on the axis.
a) If homing words without issue goto 6.
b) If gantry stops goto 8.
Have high value for SGTHRS now going to look for the lower level
set lowSGTHRS = SGTHRS
set highSGTHRS = highSGTHRS - incVar
Run homing on the axis.
a) If homing words without issue goto 9.
set SGTHRS = ( highSGTHRS - lowSGTHRS ) / 2
Run homing one more time to confirm SGTHRS value works as expected
Two things. First off, this is the first time I’ve tried to document the process that I follow when I’m setting the sensorless homing values. I’m going to confirm it on one of my printers in an hour or so but I think it’s right.
However, I may have made a mistake in it, so please try it and see how it works for you.
Wow! Flashbacks to high school math. I will try that but here’s the latest. I switched Y back to using the switch that was still on the printer but unplugged. It works but now that I can move the axis I found out that when one axis moves the other also moves so the head moves on a diagonal.
I should give you the full picture here in case there’s something else I messed up. When I put the new tool head on I replaced the belts because the old ones were too short to reuse. While doing so I found several of the (cheap) idler pulleys were really bad. On the suggestion of another Voron guy I replaced all the idlers with flanged bearings that are about 2.5mm smaller in diameter than the original which I assumed as idlers shouldn’t make a difference. I was ready to configure Marlin when Amazon had a Black Friday special on the Pad 7 and since converting to Klipper was in the plan anyway, well here we are.
So, any thoughts on the movement issue before I delve back into the homing? I really appreciate you taking the time to help me with this.
This is a CoreXY printer - have you set that in your kinematics setting in printer.cfg:
[printer]
kinematics: corexy
Anyway, I just spent a couple of hours playing around with the algorithm above and, to my surprise, the SGTHRS values are quite intolerant to stepper current. I still prefer and recommend minimizing stepper current during homing to minimize the chance of damage to your 3D printer.
The printer I used is an old Sapphire Pro that I use to test different boards and electronics. For the last main controller board I had, the SGTHRS values for X & Y were both 70.
I ran through the algorithm above twice, once for a homing current of 0.4A and once for 0.6A. After working through the algorithm above, I got an SGTHRS value of 68.
I should have run through the algorithm before posting above because what I didn’t realize is that you do get a pretty good Console message if the SGTHRS value is too high - “Endstop # still triggered” (where “#” is “X” or “Y”). This may come up without the gantry moving or after it moves to the end point. I recommend that you use something like my macro above where after going to the endstop, the gantry moves to the middle of the build surface for the next homing operation - this is a good indicator that something is wrong.
On the other end of the scale, you’ll have to use some judgement. The idea situation is that the gantry hits the endstop once and then moves to the middle point. Sometimes there is a retry which you may consider to be a good sensorless homing but in other cases there will be a definite and heavy “Clunk” and retry which is a failure.
Going through the algorithm I realized that I could simplify things by not looking for an initial value that works, instead looking for the highest value that works followed by the lowest and then using the mean.
The updated algorithm is:
Start at the halfway point
set SGTHRS = 128
set incVar = 128
Run homing on the axis. The object of this part of the algorithm is to find the highest value that doesn’t give the “Endstop # Still Triggered” message.
set incVar = incVar / 2
a) if incVar == 2 then goto 3. SGTHRS is basically at the highest value that doesn’t give the “Endstop # Still Triggered” message. This value of “2” is an arbitrary value which means the smallest increment/decrement value is four - This works for me but you might want to try something different.
b) If you get the “Endstop Still triggered” the Gantry just stops then you are too sensitive: set SGTHRS = SGTHRS - incVar/goto 2.
c) set SGTHRS = SGTHRS + incVar/goto 2. This assumes that the Gantry moves to the endstop and then to the middle of the axis’ rail. We’re not working about the heavy “Clunk” at this point.
set highSGTHRS = SGTHRS
set incVar = highSGTHRS / 2
Run homing on the axis. The object of this part of the algorithm is to find the lowest value that doesn’t give a heavy “Clunk” when the gantry comes in contact with the endstop.
set incVar = incVar / 2
a) if incVar == 2 then goto 5. SGTHRS is at the lowest value that doesn’t have a heavy “Clunk” when the gantry comes in contact with the endstop. Like in point 2x, this value of “2” is an arbitrary value which means the smallest increment/decrement value is four.
b) If you get a heavy “Clunk” then you are not sensitive enough: set SGTHRS = SGTHRS + incVar/goto 4.
c) set SGTHRS = SGTHRS - incVar/goto 2. This assumes that the Gantry moves to the endstop and then to the middle of the axis’ rail without a warning message or a heavy “Clunk”.
set lowSGTHRS = SGTHRS
set SGTHRS = ( highSGTHRS + lowSGTHRS ) / 2 This will be your SGTHRS value for the axis and should run without the “Endstop Still triggered” or a heavy “Clunk”.
I wish there was some way to detect when the SGTHRS register is too low rather than deciding on whether or not the “Clunk” is heavy or not - then setting the SGTHRS value could be done automagically.
As it is, it might be helpful to write a macro that runs a single axis homing operation with a specific SGTHRS value and avoid going back and forth between the main screen and printer.cfg.
@stolowma could you a) check your printer.cfg for the corexy specification and b) try the improved algorithm above and let me know how it works for you.
I think I may have found the source of the problem(s). While giving the printer a once over to check for any obvious mechanical issues I discovered one of the belts was noticeably looser than the other. Not sure why unless it stretched when the printer crashed into the endstops. It appears to be doing what it’s supposed to now. Are these corexy’s that sensitive to belt tension?
When I get the Y set back to sensorless I’ll run through those algorithms to get everything fine tuned. As far as writing a macro as you described I think I’ll get more of the basics down before checking out that rabbit hole. Thanks again for your help.
CoreXY’s aren’t that sensitive to belt tension - when you say that one “noticeably looser” I would expect to mean that it was basically falling off the drive and idler gears so that no force was transferred to it.
When I was talking about the macros, I was thinking of me writing them but if you’re game…
No it wasn’t that loose, I didn’t think that would make that much difference. But it’s working since I tightened it a bit so… I have no explanation. Right now I’m going by the if it works don’t fix it mantra and move on to the next thing I can bug you about.
As far as the macros I wouldn’t want to deny you the joy and satisfaction of writing them not to mention that’s a bit above my pay grade at this time.
Yes, I’m going to leave the Y axis homing using the switch for the time being and revisit it later.
If that’s the case I think that was the problem and it was slipping when it tried to home. I still don’t understand how it loosened like that, I must have not adjusted properly when I replaced it.
I will try that but here’s the latest. I switched Y back to using the switch that was still on the printer but unplugged. It works but now that I can move the axis I found out that when one axis moves the other also moves so the head moves on a diagonal.
not to mention that’s a bit above my pay grade at this time.