Very informative, while being tolerant and thoughtful of other mods and how they impact sensor less homing. Great job reminding people to adapt this for their use, not blindly copy. Also thank you for citing sources and collaborating members of the Voron community to solve oddities and problems, what a great example. Great Job.
This is exactly what I have been looking for! I searched so many videos for a tutorial about the homing macro so I could do the homing retract, but could not find anything. You should probably put homing macro into the video title or in description too just in case your video is skipped over when people are searching.
I refuse to try, but by watching your videos, it helps me learn the different possibilities. Thank you, very informative to dive deepers in 3D printers and mods
Got it working, and it works really well. But I did go with the more sensitive values. Edit: I ran into an issue that i solved, in case anyone else has it. Homing X worked perfectly, Y sort of crashed resulting in endstops being slightly off-set. Issue was that if you have a homing override in your printer.cfg then klipper will use that instead of the homing override in homing.cfg/sensorless.cfg(whatever you decided to call it). Simply comment out the override and everything will work perfectly.
Those sensitivity settings should be different for each printer. It depends on so many variables. I was really worried about making my values available to others. I'm glad you got this working! I'm very happy with it.
@@KapmansBasementWorkshop oh I used my own :p followed the process of checking values till it worked. Having an odd isuue with Y though. It sort of crashes when using the home all command. But if I just home Y it works perfectly. Makes no sense. Acting like it has low sensitivity when using home all but only homing Y works like it has correct sensitivity.
I run 5 vorons and have tried sensorless homing. It just cant be trusted as SOOO many things cause a false positive. Voron was built for microswitches and SHOULD be used IMO. This is of couse my own experience and might not reflect what you might encounter but I've had to go back and add microswitches to my recent build.
@@KapmansBasementWorkshop Hey thanks for taking the time to respond. But as a member of a very niche community I would encourage you not to promote sensor less vs microswitches. I run a print farm that produces parts and with thousands of hours on each of my printers microswitches are absolutely the way to go. I have never had a single microswitch fail vs tons of failures from sensor less. Things happen when your pushing a tethered cable around (using canbus) and that will cause more problems. Spend the extra 10cencts per microswitch to get good ones and then they wont fail even after 6-10 years.
Thanks! I was just finishing the canbus mod and decided to do this mod too. Works like a charm! Still using Euclid and auto-z. I do not (yet) have a problem with switches failing. (probing bed at 110 C) I use a z-speed of 2. I noticed that higher speeds (I.e. 5) the switch seems to bang the bed. (I have a switch offset of 0.40)
I'm glad to hear it! I always kept mine on the slow side for anything that probed the bed. I saved faster speeds for when moving away from the bed. And sensorless for X & Y has been good. No complaints here. Thank you for the comments!
I have a tempered glass build plate, so I am currently using tap with the optical sensor. I actually probe at full printing temperature with a diamondback nozzle which works great, however there is still some thermal drift to the z offset. I plan to try a custom mod where I will simply break a circuit as the nozzle and gantry probes around. I'm hoping it will work at more extreme temperatures without any sensors or "low" temperature limit switches. My goal is a 200C build plate and >160C chamber. The higher temperatures mean I will need to switch to an umbilical without canbus and without sensors, and only wires going to the hotend assembly.
z offset due to thermal drift will alway happen unless you warm your chamber for a long time before you print and keep it warm. But I think I saw someone writing a script where it compensate of the drift overtime
I have been using sensorless for along time, but I was missing the homing override as well as the other advanced macros you showed. This is very helpful, thank you very much for makin this tutorial video. We need more klipper tutorials. Can you please do one for canbridge on boards that support it?
@Kapman's Basement Workshop I'll give you a little hint.... use a BTT Manta Board and octopus 🐙. Again thank you so much for the tutorials you provide. You really help fill in the gaps that the documentation never explains properly. Klipper has so many capabilities but not all of us have the time to read and connect the dots with documentation and community assistance.
First up, really great video! I really like the pace at which you explain the concept and the necessary documents. Perhaps you might want to consider normalising the voice as it does get louder and softer sometimes, but overall a 9.9/10 video! Sadly, I sometimes get failed prints due to the undervoltage error. It more often happens after I QGL my voron 2.4r2, and try to G28 it. Replaced the TMC drivers, changed the wiring, but it intermittently occurs. Went back to X/Y endstops and the problem disappeared; and I'm not sure why.
For the under voltage error, you could try lowering the run current during those operations. On x & y I run very high current. Dropping that a bit helped. Also, you should have a look at this: github.com/Esoterical/voron_canbus/blob/main/toolhead_flashing/common_hardware/BigTreeTech%20SB2209%20and%20SB2240/SB2240%20Stepper%20Configuration%20and%20Undervoltage.md It's a different TMC driver, but I'm willing to bet much of it works for 2209's and others. Thanks for watching!
@@KapmansBasementWorkshop I'm actually running 0.8a, I'll try dropping that a little to see if it works. Thank you so much for the guidance once again! #subscribed
@@Kravenovic Just so you are aware, I was running my XY motors at 1.4. I dropped them to 1.2 on the current and so far, I have not seen this anymore. But more time is needed. And I have no idea what this appeared.
Amazing tutorial, thank you so much! I've been preparing myself to make this on the weekend, but it turned out to be quite simple and easy! Now with SB2040 I can campletely remove the drag chains
I won't have sensorless homing anytime soon. How are the switches failing? You connect them in NC mode right, so if the switch has failed, it must register instantly triggered and prevent further movement, i would think? A little bit of a dumb idea but like... i guess i can just run a ground pad to the moving part and the stationary part can be a pulled up pad. Just a steel-nickel strip. Not ideal because that would have to be in NO mode.
This is an enclosed 3d printer. The internal temps get between 60c and 70c. I think that approaches the switch's operating limit of 80c. I also think soldering wires to the switch, if you are not quick enough about it causes some damage to the switch as well. The combination of the two means the switch doesn't last as long as I would suspect.
@@KapmansBasementWorkshop So here's a not-so-hot tip, you don't have to solder wires to switches. You can use fitting spade plugs. People less inclined to crimp can order endstop spade wire premade from various Reprap and Ramps suppliers. When using spade plugs, switches must be connected in NC (normally closed) mode. This way, if the connector degrades or the wires get tugged and fall off, the endstop is interpreted as triggered without actuation and should stop hazardous movement. But i say the hole in the switch terminal actually locks the spades pretty nicely! Also see Alex Kenis video Failing Switch Problem: Omron vs the Modern Mouse Circuit. This dude is excellent at building 3D printers, but this time he is talking about something else but it still applies. Thing is our endstop switches while different in size, they have the same type of internal construction and guaranteed also the same problem. In short, if you run a 32bit board with 3V3 IO logic voltage, the switch is operated outside spec on the current-voltage curve with either or both being too low. Normally, the switched power electrically causes an impact to oxide that forces it to flake off. If the current and voltage are too low, the switch experiences continued oxide growth. At elevated temperature, even within switch's operating range, the oxide growth is much accelerated. I also think switches should ideally be coated with a layer of deoxit d5 inside. See Applied Science: How Corrosion Inhibitor Protects Metal. Alex concurs, when i talked to him about it. There is a way to run switches harder, you can run them from 12 or 24V high rail. One side of the switch gets connected to this rail via a pullup resistor corresponding to a suitable current according to switch spec, and in parallel this same side of the switch gets connected to the microcontroller input via an 1n4148 standard small-signal diode, with the diode pointing away from microcontroller and towards the switch. The other side of the switch is tied to ground. Engage weak software pullup. This way when the switch is open, the microcontroller input is driven by internal pullup. The 24V rail would love to pull up the microcontroller beyond absolute maximum rating, but for that to happen the current would have to be flowing in the opposite direction of diode, which the diode prevents. However, when the switch is closed, the switch will successfully pull down the microcontroller through the diode, while the high rail and its resistor provides switch cleaning action. You can use this same high rail to logic voltage conversion trick with inductive probe as well, if you were to use one. Since you have failed to describe the failure mode, i mean whether switch fails open, fails closed, or fails no-contact, i don't know whether these approaches are applicable. I thought i wasn't too ambiguous but i guess i was.
Both are from Paramount 3D. I believe the white is just "White". The other color is Military Green. People either love it or hate it. I love it. They have some other amazing military type colors as well. I've had good experiences with their filament. Check out their "Iron Red". Amazing!
@@KapmansBasementWorkshop great man, thanks alot, im now at the "before build learning" stage (before ordering a 2.4 kit) Im lerning alot at your channel, keep going.
I have the LDO Nitehawk SB that I just installed. When going through the set up of the endstop pins for x and y do I use the original values or the update pin mappings that LDO documentation had me switch to? Referring to this section, use these values for the sensorless or the old values before the nitehawk? ##################################################################### # Endstops ##################################################################### ## XES - Toolhead PCB [stepper_x] endstop_pin: nhk:gpio13 ## YES - Toolhead PCB [stepper_y] endstop_pin: nhk:gpio12
I'm trying to setup Sensorless Homing on my Ender-Switchwire conversion, this was a very timely video, thanks! Any special considerations for the Core XZ motion system?
After playing with I returned back to microswitches. 1 Carriages strikes are too loud. I like fast homing. 2 min settings get unstable homing - it triggered before home position. You need control every home personally.
I would concur... It is like the dirty secret no one wants to talk about. While I have not had issues with the x/y endstops as of yet the klicky probe tends to go inaccurate quickly. One of my buddies on line said that he replaced them about once every 3 or 4 weeks until he went to tap. I am starting to observe somewhat the same periods of fallout. No one talks about this with klicky. The endstop should be retired at some point unless a more heat resistant switch can be found.
That sounds about right. I was changing a switch about once every month or so. The last one that went bad was the cause of destroying a brand new PEI sheet on a 350mm bed. Expensive! Thank you for the comment!
Everything I have read, no. It's not accurate enough for z. Also if you have more than one z motor, Klipper can't sensorless home more than one motor at a time. This was my 1st thought once I got this working!
@KapmansBasementWorkshop i use a load cell right now with an arduino but someone else on youtube who has a load cell said theres a way to configure klipper to use it directl without the microcontroller in between its VERY accurate. The reason i wanna get rid of it because i use a hermit crab can board to facilitate fast tool changing on my v2.4 and it would be nice to eliminate the extra bulk, i havent thought of a good way to build tap into the tool changer yet so sensorless would be ideal. Btw i am using closed loop steppers so it seems like maybe that could make the sensor less more accurate than just normal skipping step? I did try the tap on my trident and its nice too but the load cell works better. I really want to get one of rhe bed scanners something like my x1c has. My addiction to printers is not healthy for my bank account lmao. Anyways thanks for your fast reply, i love your channel. Keep up the hard work
So I gave your macro a try on my ender 3v2 running a CR-touch. There is one small issue that I'm running into, usually the g28 command makes the gantry go up by around 10mm so that the probe has room to extend. The macro is not making the gantry go up and therefore the probe is unable to deploy. I haven't changed anything major aside from the coordinates and adding a z tilt since I'm running independent z motors. Would I use a force move or something to fix this ? I'm also going to ask on discord but I just wanted to let you know about this.
the home run current is the on that you using to run the x and y motor right? sice there is in % and in the config file is not. iknow that the sensorless file said that are those but just to confirm
home_current is the current you want to use when homing. You must tune stallguard using the same value. run_current is is a place to store the default running current you have set during a print.
I have slight fear of the sensorless homing. I understand the choice to not keep breaking the endstop switches, but won't this just strain the steppers much more?
I don't see any strain on the motors. But if it's not tuned correctly, I could see sensor less damaging other parts of the printer like the gantry. So please be careful.
I'm going to assume you are correct as I have never used one. However, it is common on commercial 3d printers. The QIDI I just received has no microswitches as far as I can tell. Thank you for the comment!
Actually, no. And I state that in the video. I need to add a note. Thank you for the catch. I saw a step stick description that claimed it did, but I think that was a typo. The TMC docs say it doesn't.
Thank you for this very informative and helpful video! I have a question: how to lift the toolhead before homing? I followed your guide to do the sensorless homing and TAP. Before TAP I was using klicky , when I home all, the Z axis lift a few milimeters (maybe 20 mm?), and then start homing all axises. Now with TAP, I find it doesn't do this, sometimes (when first layer was bad and I stopped it) when I home the axises, it just move and the nozzle scatch the bed. I tried add gcode to lift Z, but it won't let me do it before homing. I tried using safe_z_home which raised the toolhead. so how can do this lift z with the [homing_override] function? I see your toolhead lift when you do the G28 X0, how do you do that?
The code should look like this: [homing_override] axes: xyz set_position_z: 0 gcode: G1 Z10 ## Test {% 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 %} G90 G1 X175 Y175 F12000 ## Change this. Should home to the z endstop pin if you don't use TAP. Also, this is for a Voron 2.4 350. G28 Z ## Home Z G1 Z10 F1200 {% endif %}
@@KapmansBasementWorkshop Thank you very much for your reply! I tried your code and it worked perfectly. I like your video, it has all the details for beginners like me!
Any Idea what this means when I try to home? Move out of range: -10.000 0.000 0.000 [0.000] EDIT1: I found out what this issue was. your x and y home position is -10 but my min for x and y is 0, so i just changed the -10 to 0 and it worked. Edit2: I managed to get mine working perfectly with lots of small tweaks to the current, feedrate, accel, and other settings, but I am bummed out about something. With the Z safe homing, it will lower the bed slightly before it homes X/Y, but with this sensorless macro, it does not do that which could cause a nozzle drag if the bed is not low enough to start with.
Compare your homing override to mine: [homing_override] axes: xyz set_position_z: 0 ## Test gcode: G1 Z10 ## Test {% 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 %} G90 G1 X175 Y175 F12000 ## Change this. Should home to the z endstop pin if you don't use TAP. Also, this is for a Voron 2.4 350. G28 Z ## Home Z G1 Z10 F1200 {% endif %}
I honestly don't know. I don't have any power recovery electronics in my printer. But it might be a problem. If power goes out, how does the printer home with the print on the bed? And since this method isn't perfectly repeatable, so I'm not sure it would be able to restart the print from where it left off. I wish I knew more.
I'm a bit confuse, I though your diag pin had to be set to your old endstop pin (PA2 for x), but your diag pin is PB13, looks like I have to listen again
I posted a link in the video description to a site that shows how the pins are setup for one of the BTT boards as a good clue. But you should really go to the skr 1.3 documentation where it will show you the diagnostic pins. The Spider is a very different board.
I found my value (92) for both x and y, when the hotend is in the middle (175,175) everything is fine, but when the hotend is at the back (y=350), doing a G28 x0 only move x a bit, I have to set field SHTHRS = 50 for it to work, but that is not good because if I do a G28 x0 when the hotend is in the middle of the bed, it bang on the extrusion Have you seen this
Make sure when all power is off that when you move the hotend by hand, there are no changes in resistance. If your printer uses linear guides, make sure they are well lubricated. Also, make sure that there is enough slack with the cables to the print head so that no additional resistance is being created in that position. In short, for some reason there is more resistance in that location and you need to figure out what the cause of that is.
@@KapmansBasementWorkshop well the wiring is OK, beause i've been using this printer for a long time. If I had looks carefully, I would have seen that after a G28 x0, they actually move back 10mm , so it is never at max position (350 in my case). so it actually works fine.
Unfortunately I couldn't get it to work accurately, always about 0.5-1mm different from last home. Sometimes worse at 2mm where it can't even dock the klicky probe properly. My current optical endstops are well below 0.0001mm difference between homes, probably still better than that but my result accuracy is limited by the position readout decimal points in klipper
I'm sorry about that. I failed to think about that. On this printer, I no longer have klicky, it's just using TAP. Optical endstops are easily the most accurate. I'm considering those for a future build.
@KapmansBasementWorkshop think my issue is to do with using klicky probe with sensorless homing and the homing override are conflicting with each other
would you post a pic of your jumper configuration to put the spider in diagnostic mode? When i issue the commands to home x or y it responds with prob triggered right when it starts moving
If you find it not working consistently, you might need to make the homing speed faster. I now have that set to 60. But please be careful. If you turn up the homing speed, you will need to re calibrate sensor less homing as any previous values you calculated will then be incorrect.
Hi again! so i have my head moving but when I try to run the calibration I get this error; "Endstop x still triggered after retract" doesn't matter how low I set the SGTHRS value it pops this error every time?
@@KapmansBasementWorkshop yeah my issues was multi fold. I had the motors going backwards, I had the run current way to high, I had the sensitivity set wrong and really didn’t understand it at first. All good now got my tap, can bus and sensorless homing working well! Super happy!
@@TwitchFlys That's good news. I'm very glad to hear it's working. Over the next few days, you might need to make some minor adjustments to the sensitivity and then you should be fully done. Thanks for watching!
For sure. I got the bed mesh run one time and had to shut it down for a few weeks while I’m out of town. Go figure I get it running right before I leave.
May I introduce you to my Lord and Savior the *_Hall Effect X/Y Endstop?_* Comes with plenty of LEDs too! One can never have enough LEDs in a System! 😁 _Also_ allows for Homing Speeds beyond the 200mm/s for when you're in a bad mood and you're trying to show someone's who's Boss like: _"Your Head in there G28!"_
You may! Honestly, I need to have a look at Hall Effect sensors. I have not (knowingly) used one and I know many really like them. And homing speeds to 200mm/s? Wow! Thank you very much for the comment and watching.
I started with Hall effect, but it did not work for me for some reason. Could be a faulty board, but I just put in switches at that time and now sensorless I like that it gets rid of some wires 😁
@@gjmi72 I love the lack of wires. The inside of my printer is very clean and between this and canbus, there are so few wires that are actually connected to the MCU, it's kind of amazing.
A failed switch usually appeared as non-predictable measurements in the case of z or outright crashes into the bed. For the x & Y axis, Klipper would just stop.
@@KapmansBasementWorkshop You could offset the switches, wire them parallel, when the first one fails from prolonged use in the heated environment the second picks up the slack or use the additional on another pin as a "failsafe" set up that shuts down the printer when activated.
@@KapmansBasementWorkshop 1th issue homing one axis on center of printer but sensivite very low and around 400 grams but any way. 2th issue if you axis already on 350 point its require to add space because doing brrrrrrrrr when try to home
@KapmansBasementWorkshop i only using them on x/y no touching and they were cheap from ali. I just looked for them and not finding the product anymore but basically you can make your own with a photo resistanter and an led, it probably doesnt even need to be infrared.
The description of "sensorless homing" makes it seem like an awful idea right from the get-go. Like why not leave the switches in place and apply the code to detect missed steps and prevent damage in the event the switches fail? It seems like the whole concept trades the abuse of cheap and replaceable switches for significant wear and tear on your entire axis. if they're getting hot, they should be able to be relocated pretty easily. Or use a different means of detection. No detection at all seems like a terrible idea.
It may seem like a bad idea, but now that I have it running, it's not causing any wear on the printer. The TMC2209 driver is checking for feedback voltage from the motor to sense when it will start to miss steps. It's super sensitive. It barely touches the end of the gantry before it stops. You actually can't even hear it tap the side. Since publishing this video, there are no impact marks or anything of the kind on the gantry. This works really nice. I won't add a microswitch to the X or Y axis on any future printer build. The switches currently no longer make any sense to me. Thanks for the comments and watching!
@@KapmansBasementWorkshop touching is touching, even if it’s just a little. in the description it says to make sure your setup can mechanically take the stress. I have to imagine there’s some wear and tear happening. Considering how long my mouse switches keep working, I’d probably keep using the micro switches and add safeties for the event of a failure. Are there any professional/commercial machines that use this method? I’d think if it was a good idea and saved parts, it’d be ubiquitous
@@threepe0 The QIDI X-Smart3 that I just got is senseless as far as I can tell except for the bed which has an optical sensor. So X & Y axis are senseless and z isn't on this commercially available 3D printer. And on the Voron, the parts that touch are ABS, if they break, it's easily replaceable (I have backup spare parts that I have printed). But, I understand the concern. I had that same concern for years. This mod may not be for everyone and if you have no trouble with your setup, you have no reason to change. Thanks for commenting and watching!
Occasionally I have an issue with power outages and sensorless. Sensorless sometimes sets home 1 to 2mm off. Never had this issue with switches. So resuming a print after a power outage, it always fails. Otherwise it works great.
@@KapmansBasementWorkshop thank you for your help. I've now got klipper to load without any errors but when i try a G28 X0 to start stallguard tests i get an error unknown command "set kinematic position" any ideas
Very informative, while being tolerant and thoughtful of other mods and how they impact sensor less homing. Great job reminding people to adapt this for their use, not blindly copy. Also thank you for citing sources and collaborating members of the Voron community to solve oddities and problems, what a great example. Great Job.
Thank you for the kind words and commenting!
This is exactly what I have been looking for! I searched so many videos for a tutorial about the homing macro so I could do the homing retract, but could not find anything. You should probably put homing macro into the video title or in description too just in case your video is skipped over when people are searching.
Glad it helped! Thank you for the tip!
I refuse to try, but by watching your videos, it helps me learn the different possibilities. Thank you, very informative to dive deepers in 3D printers and mods
Thank you!
I've spent multiple hours tearing my hair out at the undervoltage error. THANK YOU for providing a solution to it!
Glad it helped! Thank you!
Got it working, and it works really well. But I did go with the more sensitive values.
Edit: I ran into an issue that i solved, in case anyone else has it. Homing X worked perfectly, Y sort of crashed resulting in endstops being slightly off-set. Issue was that if you have a homing override in your printer.cfg then klipper will use that instead of the homing override in homing.cfg/sensorless.cfg(whatever you decided to call it). Simply comment out the override and everything will work perfectly.
Those sensitivity settings should be different for each printer. It depends on so many variables. I was really worried about making my values available to others. I'm glad you got this working! I'm very happy with it.
@@KapmansBasementWorkshop oh I used my own :p followed the process of checking values till it worked.
Having an odd isuue with Y though. It sort of crashes when using the home all command. But if I just home Y it works perfectly. Makes no sense. Acting like it has low sensitivity when using home all but only homing Y works like it has correct sensitivity.
@ivyr336 did you ever find a solution as I'm having the same issue
@@aaronharnett7938 Original comment has an edit with solution
Another great video from a great channel. Thanks!
Thank you very much!
I run 5 vorons and have tried sensorless homing. It just cant be trusted as SOOO many things cause a false positive. Voron was built for microswitches and SHOULD be used IMO. This is of couse my own experience and might not reflect what you might encounter but I've had to go back and add microswitches to my recent build.
I'm sorry it did not work out for you. My Voron 2.4 and my v0.2 both are sensorless and they work well. But thank you for the feedback.
@@KapmansBasementWorkshop Hey thanks for taking the time to respond. But as a member of a very niche community I would encourage you not to promote sensor less vs microswitches. I run a print farm that produces parts and with thousands of hours on each of my printers microswitches are absolutely the way to go. I have never had a single microswitch fail vs tons of failures from sensor less. Things happen when your pushing a tethered cable around (using canbus) and that will cause more problems. Spend the extra 10cencts per microswitch to get good ones and then they wont fail even after 6-10 years.
@@microcontrolledbot Thanks for commenting and watching.
Amazing work. Thanks for the detailed explanation. It was easy to follow and prefectly informative
Glad it was helpful! Thank you for the nice comments and for watching!
Thank you for this. I'm having issues with my microswitches, and I'm leaning towards this route.
This can help. It will certainly take some tuning. And after the printer has warmed up, it may require a little more tuning. But I'm happy with it.
Thanks! I was just finishing the canbus mod and decided to do this mod too. Works like a charm! Still using Euclid and auto-z. I do not (yet) have a problem with switches failing. (probing bed at 110 C) I use a z-speed of 2. I noticed that higher speeds (I.e. 5) the switch seems to bang the bed. (I have a switch offset of 0.40)
I'm glad to hear it! I always kept mine on the slow side for anything that probed the bed. I saved faster speeds for when moving away from the bed. And sensorless for X & Y has been good. No complaints here. Thank you for the comments!
I have a tempered glass build plate, so I am currently using tap with the optical sensor. I actually probe at full printing temperature with a diamondback nozzle which works great, however there is still some thermal drift to the z offset. I plan to try a custom mod where I will simply break a circuit as the nozzle and gantry probes around. I'm hoping it will work at more extreme temperatures without any sensors or "low" temperature limit switches. My goal is a 200C build plate and >160C chamber. The higher temperatures mean I will need to switch to an umbilical without canbus and without sensors, and only wires going to the hotend assembly.
I'd love to see that and I'd love to give it a try. When you are ready, please let me know!
z offset due to thermal drift will alway happen unless you warm your chamber for a long time before you print and keep it warm.
But I think I saw someone writing a script where it compensate of the drift overtime
@@yvesinformel221 I've seen it. At some point, I'll give it a try.
What is the benefit of using glass instead of pei ? When i got into 3d everything is pei sheet already
Awesome detailed explanation, thank you!
Thank you!
I have been using sensorless for along time, but I was missing the homing override as well as the other advanced macros you showed. This is very helpful, thank you very much for makin this tutorial video. We need more klipper tutorials. Can you please do one for canbridge on boards that support it?
I just need an mcu that supports it.... Soon. Thank you for the kind words and watching!
@Kapman's Basement Workshop I'll give you a little hint.... use a BTT Manta Board and octopus 🐙. Again thank you so much for the tutorials you provide. You really help fill in the gaps that the documentation never explains properly. Klipper has so many capabilities but not all of us have the time to read and connect the dots with documentation and community assistance.
@@hermangaviria690 I can't promise anything yet, but let me see what I can do.
First up, really great video! I really like the pace at which you explain the concept and the necessary documents. Perhaps you might want to consider normalising the voice as it does get louder and softer sometimes, but overall a 9.9/10 video!
Sadly, I sometimes get failed prints due to the undervoltage error. It more often happens after I QGL my voron 2.4r2, and try to G28 it.
Replaced the TMC drivers, changed the wiring, but it intermittently occurs. Went back to X/Y endstops and the problem disappeared; and I'm not sure why.
For the under voltage error, you could try lowering the run current during those operations. On x & y I run very high current. Dropping that a bit helped. Also, you should have a look at this: github.com/Esoterical/voron_canbus/blob/main/toolhead_flashing/common_hardware/BigTreeTech%20SB2209%20and%20SB2240/SB2240%20Stepper%20Configuration%20and%20Undervoltage.md
It's a different TMC driver, but I'm willing to bet much of it works for 2209's and others.
Thanks for watching!
@@KapmansBasementWorkshop I'm actually running 0.8a, I'll try dropping that a little to see if it works. Thank you so much for the guidance once again! #subscribed
@@Kravenovic Just so you are aware, I was running my XY motors at 1.4. I dropped them to 1.2 on the current and so far, I have not seen this anymore. But more time is needed. And I have no idea what this appeared.
Amazing tutorial, thank you so much! I've been preparing myself to make this on the weekend, but it turned out to be quite simple and easy!
Now with SB2040 I can campletely remove the drag chains
I was pushing this off for a long time. Once I did it, not sure why I postponed this. I should have done it sooner! Thanks for watching!
Awesome work sir
Thank you for the nice comment!
@@KapmansBasementWorkshop Do you have a preference for SPI or UART? V2.4, OctPro, BTT TMC2209s
I won't have sensorless homing anytime soon.
How are the switches failing? You connect them in NC mode right, so if the switch has failed, it must register instantly triggered and prevent further movement, i would think?
A little bit of a dumb idea but like... i guess i can just run a ground pad to the moving part and the stationary part can be a pulled up pad. Just a steel-nickel strip. Not ideal because that would have to be in NO mode.
This is an enclosed 3d printer. The internal temps get between 60c and 70c. I think that approaches the switch's operating limit of 80c. I also think soldering wires to the switch, if you are not quick enough about it causes some damage to the switch as well. The combination of the two means the switch doesn't last as long as I would suspect.
@@KapmansBasementWorkshop So here's a not-so-hot tip, you don't have to solder wires to switches. You can use fitting spade plugs. People less inclined to crimp can order endstop spade wire premade from various Reprap and Ramps suppliers.
When using spade plugs, switches must be connected in NC (normally closed) mode. This way, if the connector degrades or the wires get tugged and fall off, the endstop is interpreted as triggered without actuation and should stop hazardous movement. But i say the hole in the switch terminal actually locks the spades pretty nicely!
Also see Alex Kenis video Failing Switch Problem: Omron vs the Modern Mouse Circuit. This dude is excellent at building 3D printers, but this time he is talking about something else but it still applies. Thing is our endstop switches while different in size, they have the same type of internal construction and guaranteed also the same problem. In short, if you run a 32bit board with 3V3 IO logic voltage, the switch is operated outside spec on the current-voltage curve with either or both being too low. Normally, the switched power electrically causes an impact to oxide that forces it to flake off. If the current and voltage are too low, the switch experiences continued oxide growth. At elevated temperature, even within switch's operating range, the oxide growth is much accelerated.
I also think switches should ideally be coated with a layer of deoxit d5 inside. See Applied Science: How Corrosion Inhibitor Protects Metal. Alex concurs, when i talked to him about it.
There is a way to run switches harder, you can run them from 12 or 24V high rail. One side of the switch gets connected to this rail via a pullup resistor corresponding to a suitable current according to switch spec, and in parallel this same side of the switch gets connected to the microcontroller input via an 1n4148 standard small-signal diode, with the diode pointing away from microcontroller and towards the switch. The other side of the switch is tied to ground. Engage weak software pullup. This way when the switch is open, the microcontroller input is driven by internal pullup. The 24V rail would love to pull up the microcontroller beyond absolute maximum rating, but for that to happen the current would have to be flowing in the opposite direction of diode, which the diode prevents. However, when the switch is closed, the switch will successfully pull down the microcontroller through the diode, while the high rail and its resistor provides switch cleaning action.
You can use this same high rail to logic voltage conversion trick with inductive probe as well, if you were to use one.
Since you have failed to describe the failure mode, i mean whether switch fails open, fails closed, or fails no-contact, i don't know whether these approaches are applicable. I thought i wasn't too ambiguous but i guess i was.
NICE job!
Thank you!
just wanted to say your video's have helped me a great deal.
Thanks so great to hear. Thanks so much for the kind words and watching.
Tanks for your content, must ask, what is the color and brand of your white and green voron v2.4?
Both are from Paramount 3D. I believe the white is just "White". The other color is Military Green. People either love it or hate it. I love it. They have some other amazing military type colors as well. I've had good experiences with their filament. Check out their "Iron Red". Amazing!
@@KapmansBasementWorkshop great man, thanks alot, im now at the "before build learning" stage (before ordering a 2.4 kit)
Im lerning alot at your channel, keep going.
@@dansaada I'll continue to work on it. Good luck with your future build!
I have the LDO Nitehawk SB that I just installed. When going through the set up of the endstop pins for x and y do I use the original values or the update pin mappings that LDO documentation had me switch to? Referring to this section, use these values for the sensorless or the old values before the nitehawk?
#####################################################################
# Endstops
#####################################################################
## XES - Toolhead PCB
[stepper_x]
endstop_pin: nhk:gpio13
## YES - Toolhead PCB
[stepper_y]
endstop_pin: nhk:gpio12
You must use the LDO MCU pinouts. Fair warning in that I have no experience with the LDO controller. I wish you a great build.
I'm trying to setup Sensorless Homing on my Ender-Switchwire conversion, this was a very timely video, thanks! Any special considerations for the Core XZ motion system?
My apologies as I've not built a switchwire. But I think as long as you just apply this to X & Y you should be fine. Thanks for watching!
Great video, but I have a doubt, Is necessary that the nozzle all time need to be in the center to do this?
I'm not sure honestly.
After playing with I returned back to microswitches.
1 Carriages strikes are too loud. I like fast homing.
2 min settings get unstable homing - it triggered before home position. You need control every home personally.
I'm sorry it didn't work for you. Thanks for the comments.
I would concur... It is like the dirty secret no one wants to talk about. While I have not had issues with the x/y endstops as of yet the klicky probe tends to go inaccurate quickly. One of my buddies on line said that he replaced them about once every 3 or 4 weeks until he went to tap. I am starting to observe somewhat the same periods of fallout. No one talks about this with klicky. The endstop should be retired at some point unless a more heat resistant switch can be found.
That sounds about right. I was changing a switch about once every month or so. The last one that went bad was the cause of destroying a brand new PEI sheet on a 350mm bed. Expensive!
Thank you for the comment!
never had an issue with switches, going on 2 years on the same one.
Thanks Kap. I had to set Interpolate to False else I had undervoltage issues. Do you know if homing with Z hop is an option or is it a problem?
Hmmmm. I never would have guessed. Thank you for posting your solution!
If I understand correctly, homing with z-hop should not be a problem.
Will this work for z axis then no need for the tap thing and alot easier. Good video
Everything I have read, no. It's not accurate enough for z. Also if you have more than one z motor, Klipper can't sensorless home more than one motor at a time. This was my 1st thought once I got this working!
@KapmansBasementWorkshop i use a load cell right now with an arduino but someone else on youtube who has a load cell said theres a way to configure klipper to use it directl without the microcontroller in between its VERY accurate. The reason i wanna get rid of it because i use a hermit crab can board to facilitate fast tool changing on my v2.4 and it would be nice to eliminate the extra bulk, i havent thought of a good way to build tap into the tool changer yet so sensorless would be ideal. Btw i am using closed loop steppers so it seems like maybe that could make the sensor less more accurate than just normal skipping step?
I did try the tap on my trident and its nice too but the load cell works better. I really want to get one of rhe bed scanners something like my x1c has. My addiction to printers is not healthy for my bank account lmao.
Anyways thanks for your fast reply, i love your channel. Keep up the hard work
@@98f5 I'm dreaming of a load cell as well! Closed loop steppers should be more accurate in these situations...I think.
Thank you!
So I gave your macro a try on my ender 3v2 running a CR-touch. There is one small issue that I'm running into, usually the g28 command makes the gantry go up by around 10mm so that the probe has room to extend. The macro is not making the gantry go up and therefore the probe is unable to deploy. I haven't changed anything major aside from the coordinates and adding a z tilt since I'm running independent z motors. Would I use a force move or something to fix this ? I'm also going to ask on discord but I just wanted to let you know about this.
The maco does not move z up at all. I think you could, try a force move, but I have not tried it.
helped me so far!! thanks:)
Glad it helped!
the home run current is the on that you using to run the x and y motor right? sice there is in % and in the config file is not. iknow that the sensorless file said that are those but just to confirm
home_current is the current you want to use when homing. You must tune stallguard using the same value.
run_current is is a place to store the default running current you have set during a print.
@@KapmansBasementWorkshop got it thanks. So run current is for printing a home current is for homing.
I have slight fear of the sensorless homing. I understand the choice to not keep breaking the endstop switches, but won't this just strain the steppers much more?
I don't see any strain on the motors. But if it's not tuned correctly, I could see sensor less damaging other parts of the printer like the gantry. So please be careful.
Thanks for the great video. isn't this a similar technique to how prusaMK3 works?
I'm going to assume you are correct as I have never used one. However, it is common on commercial 3d printers. The QIDI I just received has no microswitches as far as I can tell. Thank you for the comment!
@@KapmansBasementWorkshop Thank yo ufor your answer. :) PS. i think i want same upgrade in future when get similar problems with swiches.
@@andriusanryy5165 Between this and canbus, there are so few wires left on my printer. If I could just get rid of the rest :)
The TMC2208 driver doesn't support stallGuard, right?
Actually, no. And I state that in the video. I need to add a note. Thank you for the catch. I saw a step stick description that claimed it did, but I think that was a typo. The TMC docs say it doesn't.
Thank you for this very informative and helpful video! I have a question: how to lift the toolhead before homing? I followed your guide to do the sensorless homing and TAP. Before TAP I was using klicky , when I home all, the Z axis lift a few milimeters (maybe 20 mm?), and then start homing all axises. Now with TAP, I find it doesn't do this, sometimes (when first layer was bad and I stopped it) when I home the axises, it just move and the nozzle scatch the bed. I tried add gcode to lift Z, but it won't let me do it before homing. I tried using safe_z_home which raised the toolhead. so how can do this lift z with the [homing_override] function? I see your toolhead lift when you do the G28 X0, how do you do that?
The code should look like this:
[homing_override]
axes: xyz
set_position_z: 0
gcode:
G1 Z10 ## Test
{% 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 %}
G90
G1 X175 Y175 F12000 ## Change this. Should home to the z endstop pin if you don't use TAP. Also, this is for a Voron 2.4 350.
G28 Z ## Home Z
G1 Z10 F1200
{% endif %}
@@KapmansBasementWorkshop Thank you very much for your reply! I tried your code and it worked perfectly. I like your video, it has all the details for beginners like me!
@@goldon999 I'm super glad it was helpful. Thanks!
FYI there is a typo in sensorless.cfg, line 48
Thank you for that! I just fixed it. It's now properly commented out.
Any Idea what this means when I try to home? Move out of range: -10.000 0.000 0.000 [0.000] EDIT1: I found out what this issue was. your x and y home position is -10 but my min for x and y is 0, so i just changed the -10 to 0 and it worked.
Edit2: I managed to get mine working perfectly with lots of small tweaks to the current, feedrate, accel, and other settings, but I am bummed out about something. With the Z safe homing, it will lower the bed slightly before it homes X/Y, but with this sensorless macro, it does not do that which could cause a nozzle drag if the bed is not low enough to start with.
Compare your homing override to mine:
[homing_override]
axes: xyz
set_position_z: 0 ## Test
gcode:
G1 Z10 ## Test
{% 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 %}
G90
G1 X175 Y175 F12000 ## Change this. Should home to the z endstop pin if you don't use TAP. Also, this is for a Voron 2.4 350.
G28 Z ## Home Z
G1 Z10 F1200
{% endif %}
What about power recovery with sensorless homing. Still works? Thanks for your video.
I honestly don't know. I don't have any power recovery electronics in my printer. But it might be a problem. If power goes out, how does the printer home with the print on the bed? And since this method isn't perfectly repeatable, so I'm not sure it would be able to restart the print from where it left off. I wish I knew more.
@@KapmansBasementWorkshop Power loss recovery, when implemented, only homes XY and doesn't home Z, uses recorded Z instead.
I'm a bit confuse, I though your diag pin had to be set to your old endstop pin (PA2 for x), but your diag pin is PB13, looks like I have to listen again
OK, I see, it's different on the Spider, I'm using old SKR 1.3, maybe it's the same
I posted a link in the video description to a site that shows how the pins are setup for one of the BTT boards as a good clue. But you should really go to the skr 1.3 documentation where it will show you the diagnostic pins. The Spider is a very different board.
ok found my problem, my x endstop was set to pin 1.28, but for sensorless, I had to set it to pin 1.29 not 1.28
@@KapmansBasementWorkshop thanks, I found the problem, my x endstop was at pin 1.28, but I had to use 1.29 (xdiag) for sensorless
@@yvesinformel221 I'm glad you found it. And thanks for posting how you solved it. Hopefully others can make use of this.
I found my value (92) for both x and y, when the hotend is in the middle (175,175) everything is fine, but when the hotend is at the back (y=350), doing a G28 x0 only move x a bit, I have to set field SHTHRS = 50 for it to work, but that is not good because if I do a G28 x0 when the hotend is in the middle of the bed, it bang on the extrusion
Have you seen this
Make sure when all power is off that when you move the hotend by hand, there are no changes in resistance. If your printer uses linear guides, make sure they are well lubricated. Also, make sure that there is enough slack with the cables to the print head so that no additional resistance is being created in that position. In short, for some reason there is more resistance in that location and you need to figure out what the cause of that is.
@@KapmansBasementWorkshop well the wiring is OK, beause i've been using this printer for a long time.
If I had looks carefully, I would have seen that after a G28 x0, they actually move back 10mm , so it is never at max position (350 in my case). so it actually works fine.
@@yvesinformel221 Great news!
Unfortunately I couldn't get it to work accurately, always about 0.5-1mm different from last home. Sometimes worse at 2mm where it can't even dock the klicky probe properly. My current optical endstops are well below 0.0001mm difference between homes, probably still better than that but my result accuracy is limited by the position readout decimal points in klipper
I'm sorry about that. I failed to think about that. On this printer, I no longer have klicky, it's just using TAP. Optical endstops are easily the most accurate. I'm considering those for a future build.
Are you just using an IR Pair with something to interrupt?
Only issue i have is that when it homes it meant to bring the y out by -10 mine doesnt so i clanks the back rail
Do you have it setup like this for homing Y?
G28 Y0
# Move away so the x-axis is no longer touching the back of the gantry
G91
G1 Y-10 F1200
G4 P2000
@KapmansBasementWorkshop yes but it doesn't move away on the x or the y
@KapmansBasementWorkshop think my issue is to do with using klicky probe with sensorless homing and the homing override are conflicting with each other
@@aaronharnett7938 That may be the case. But I don't know for sure.
would you post a pic of your jumper configuration to put the spider in diagnostic mode? When i issue the commands to home x or y it responds with prob triggered right when it starts moving
never mind. i have them set just like the documentation says.
If you find it not working consistently, you might need to make the homing speed faster. I now have that set to 60. But please be careful. If you turn up the homing speed, you will need to re calibrate sensor less homing as any previous values you calculated will then be incorrect.
Hi again! so i have my head moving but when I try to run the calibration I get this error; "Endstop x still triggered after retract" doesn't matter how low I set the SGTHRS value it pops this error every time?
Have you set the virtual endstop and homing override?
@@KapmansBasementWorkshop yeah my issues was multi fold. I had the motors going backwards, I had the run current way to high, I had the sensitivity set wrong and really didn’t understand it at first. All good now got my tap, can bus and sensorless homing working well! Super happy!
@@TwitchFlys That's good news. I'm very glad to hear it's working. Over the next few days, you might need to make some minor adjustments to the sensitivity and then you should be fully done. Thanks for watching!
For sure. I got the bed mesh run one time and had to shut it down for a few weeks while I’m out of town. Go figure I get it running right before I leave.
could i use sensorless homing in the z axis ??
No, you should not. It's not accurate enough for the z axis. It sure would be cool if we could.....
ok @@KapmansBasementWorkshop
May I introduce you to my Lord and Savior the *_Hall Effect X/Y Endstop?_* Comes with plenty of LEDs too! One can never have enough LEDs in a System! 😁
_Also_ allows for Homing Speeds beyond the 200mm/s for when you're in a bad mood and you're trying to show someone's who's Boss like: _"Your Head in there G28!"_
You may! Honestly, I need to have a look at Hall Effect sensors. I have not (knowingly) used one and I know many really like them. And homing speeds to 200mm/s? Wow! Thank you very much for the comment and watching.
I started with Hall effect, but it did not work for me for some reason. Could be a faulty board, but I just put in switches at that time and now sensorless
I like that it gets rid of some wires 😁
@@gjmi72 I love the lack of wires. The inside of my printer is very clean and between this and canbus, there are so few wires that are actually connected to the MCU, it's kind of amazing.
If your stops are failing you can use 2 in parallel.
Honest question, how do you know one of them failed?
@@SneakyFrog test periodically if they are in a adverse environment.
A failed switch usually appeared as non-predictable measurements in the case of z or outright crashes into the bed. For the x & Y axis, Klipper would just stop.
Do you actually mount 2 switches in the same place? I'm not sure how that works?
@@KapmansBasementWorkshop You could offset the switches, wire them parallel, when the first one fails from prolonged use in the heated environment the second picks up the slack or use the additional on another pin as a "failsafe" set up that shuts down the printer when activated.
I’m using around month and it’s working very bad for me
What is happening to your printer when you home?
@@KapmansBasementWorkshop 1th issue homing one axis on center of printer but sensivite very low and around 400 grams but any way. 2th issue if you axis already on 350 point its require to add space because doing brrrrrrrrr when try to home
@@rust_game_shop It sounds like you need to re-calibrate as this should not be happening.
I just use infrared gates they are the most reliable
I will give them a try at some point....
@KapmansBasementWorkshop i only using them on x/y no touching and they were cheap from ali. I just looked for them and not finding the product anymore but basically you can make your own with a photo resistanter and an led, it probably doesnt even need to be infrared.
have to wait 2 secondes, sensorless is slow
I've wasted way more time replacing those switches!
@@KapmansBasementWorkshop well of course as Elon said "the best part is no part"
@@yvesinformel221 I fully agree. Thank you!
The description of "sensorless homing" makes it seem like an awful idea right from the get-go. Like why not leave the switches in place and apply the code to detect missed steps and prevent damage in the event the switches fail? It seems like the whole concept trades the abuse of cheap and replaceable switches for significant wear and tear on your entire axis. if they're getting hot, they should be able to be relocated pretty easily. Or use a different means of detection. No detection at all seems like a terrible idea.
It may seem like a bad idea, but now that I have it running, it's not causing any wear on the printer. The TMC2209 driver is checking for feedback voltage from the motor to sense when it will start to miss steps. It's super sensitive. It barely touches the end of the gantry before it stops. You actually can't even hear it tap the side. Since publishing this video, there are no impact marks or anything of the kind on the gantry. This works really nice. I won't add a microswitch to the X or Y axis on any future printer build. The switches currently no longer make any sense to me. Thanks for the comments and watching!
@@KapmansBasementWorkshop touching is touching, even if it’s just a little. in the description it says to make sure your setup can mechanically take the stress. I have to imagine there’s some wear and tear happening. Considering how long my mouse switches keep working, I’d probably keep using the micro switches and add safeties for the event of a failure.
Are there any professional/commercial machines that use this method? I’d think if it was a good idea and saved parts, it’d be ubiquitous
@@threepe0 The QIDI X-Smart3 that I just got is senseless as far as I can tell except for the bed which has an optical sensor. So X & Y axis are senseless and z isn't on this commercially available 3D printer. And on the Voron, the parts that touch are ABS, if they break, it's easily replaceable (I have backup spare parts that I have printed). But, I understand the concern. I had that same concern for years. This mod may not be for everyone and if you have no trouble with your setup, you have no reason to change. Thanks for commenting and watching!
Prusa Mk3 are sensorless. I was not keen on this bit after 4 years of use, it just work.
Occasionally I have an issue with power outages and sensorless.
Sensorless sometimes sets home 1 to 2mm off. Never had this issue with switches.
So resuming a print after a power outage, it always fails. Otherwise it works great.
Hi i had an sd card fail and my backup didn't work either. So full install done with a new rasp pi4 and have got so far but come up against the error tmc virtual endstop requires diag pin config.
I'm not sure where to look next.
[include sensorless.cfg]
[force move]
enable_force_move: True
[mcu]
## Obtain definition by "ls -l /dev/serial/by-id/" then unplug to verify
##--------------------------------------------------------------------
serial: /dev/serial/by-id/usb-Klipper_stm32f446xx_470048001251303431333234-if00
restart_method: command
##--------------------------------------------------------------------
[include mainsail.cfg]
[printer]
kinematics: corexy
max_velocity: 300
max_accel: 3000 #Max 4000
max_z_velocity: 15 #Max 15 for 12V TMC Drivers, can increase for 24V
max_z_accel: 350
square_corner_velocity: 5.0
#####################################################################
# X/Y Stepper Settings
#####################################################################
## B Stepper - Left
## Connected to MOTOR_0
## Endstop connected to DIAG_0
[stepper_x]
step_pin: PF13
dir_pin: !PF12
enable_pin: !PF14
rotation_distance: 40
microsteps: 32
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
##endstop_pin: PG6
position_min: 0
##sensorless homing
endstop_pin: tmc2209_stepper_x:virtual_endstop
##--------------------------------------------------------------------
## Uncomment below for 250mm build
#position_endstop: 250
#position_max: 250
## Uncomment for 300mm build
#position_endstop: 300
#position_max: 300
##Uncomment for 350mm build
position_endstop: 350
position_max: 350
##--------------------------------------------------------------------
homing_speed: 40 #Max 100
homing_retract_dist: 5
homing_positive_dir: true
##sensorless homing
diag_pin: ^PG6
driver_SGTHRS: 225
## Make sure to update below for your relevant driver (2208 or 2209)
[tmc2209 stepper_x]
uart_pin: PC4
interpolate: false
run_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0
## A Stepper - Right
## Connected to MOTOR_1
## Endstop connected to DIAG_1
[stepper_y]
step_pin: PG0
dir_pin: !PG1
enable_pin: !PF15
rotation_distance: 40
microsteps: 32
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
#endstop_pin: PG9
position_min: 0
##sensorless homing
endstop_pin: tmc2209_stepper_y:virtual_endstop
##--------------------------------------------------------------------
## Uncomment for 250mm build
#position_endstop: 250
#position_max: 250
## Uncomment for 300mm build
#position_endstop: 300
#position_max: 300
## Uncomment for 350mm build
position_endstop: 350
position_max: 350
##--------------------------------------------------------------------
homing_speed: 25 #Max 100
homing_retract_dist: 5
homing_positive_dir: true
##sensorless homing
diag_pin: ^PG9
driver_SGTHRS: 225
## Make sure to update below for your relevant driver (2208 or 2209)
[tmc2209 stepper_y]
uart_pin: PD11
interpolate: false
run_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0
Have a look at my cfg files here: github.com/Kapman1/Sensorless-Homing
Hopefully that helps
@@KapmansBasementWorkshop thank you for your help. I've now got klipper to load without any errors but when i try a G28 X0 to start stallguard tests i get an error unknown command "set kinematic position" any ideas