I am using “BLTouch” for z end stop and like to continue doing so. However, I would like extra protection of torque sensing (at values that are much higher, and perhaps smoothed, than used for sensorless homing) to shutdown or pause motors. Is there a way to do that with TMC UART drivers?
At the least I would like ‘torque threshold exceeded’ detection whenever bed is moving up as z axis motor is very strong and could cause a lot of damage.
With a 4-start z screw it may work. the mechanical leverage from the thread really cuts down the stepper sensitivity, will not work well with 1 or 2 start.
Consider induction probe? it is always in position. i never get crashes. I don’t get why one would bother with BL Touch, if it is retracted, it just adds weight.
I have set up stallguard and wired DIAG pin on my printer for XY and Z (4-start screw) but honestly, it has never crashed.
Advantage of BLtouch is that it works with non-metallic surfaces whereas inductive probe does not.
I did have one crash when trying Mainsail alongside Fluidd and it was not pretty. I would like setup stallguard as a fail-safe, in case I make a mistake, misconfiguration or bug.
With that said, I am looking for a way to enable stallguard to be always on for z axis ( I think by default it is only enabled when homing ) and for klipper to shutdown z motor when stall is detected for more than a second or so.
Yah, it is surface dependant. I’ve no worries with an aluminium 3mm bed. But if you were to have a magnetic surface, hmm. may throw it off. Also, a steel plate on a magnetic surface, on an aluminium plate? Suss.
I’ve only ever used Kapton tape on aluminium tape though, happy with that and I’m in situation where I can wait few mins for bed to cool down and part just lifts off.
im searching for the same for my duett board (tmc 2660) just as a fail safe. Any updates?
The problem here is that stall detection requires calibration. There is nothing stopping you from doing this today… but there is no way to setup a failsafe / trip switch without calibrating by nozzle crashing. A 2nd Zswitch would be a more straight forward solution to the problem you are trying to solve.
Is there any guide anywhere for how to setup (and calibrate) always-on stall detection?
This doesn’t exist in Klipper, only sensorless homing.
Ok, is there any guide anywhere for how to setup (and calibrate) stall detection backup for sensor-based homing?
I don’t understand what you’re asking. Klipper does not support stall detection in any form other than homing. Configuring Klipper for sensorless homing is very well documented in the official documentation at TMC drivers - Klipper documentation
Doesn’t this mean that there’s something detecting a stall?
Isn’t this reply to the question about a failsafe also hinting at some kind of stall detection being possible as a secondary (i.e., failsafe) end stop?
Am I completely misunderstanding something here?
How would you configure a failsafe z (or x or y) switch, to abort, or preferably pause, the print if the failsafe switch triggers?
Ok, I think you guys are really reading too much into what “stallguard” does… it’s NOT skipped step detection, that requires closed loop stepper (they do exist for this purpose). It’s maybe better called “jam detection”… when it sees something VERY wrong (jammed up), it will trigger the diag pin, your software can then do whatever with this (pause, stop, trigger endstop, etc…). Even with “jam detection”, it needs calibration… just how hard does it need to jam/bind-up the gantry before it triggers? You determine this my slamming the gantry into the side harder and harder until it does(per these instructions: TMC drivers - Klipper documentation )… It’s not magic… Read this, it says everything… but keep in mind that klipper and marlin don’t necessarily support all chip features: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_V103.pdf
I will repeat again, Klipper does not support this feature. It only supports using stall guard for homing, nothing else.
I think you misread, because you’re replying with stall guard repetition to a message that has literally nothing to do with using stall guard.
Let me ask again, how do I configure 2 switches, where one is my main end stop and the other is a failsafe?
You are right, I’m not following… Sounds like I’m supposed to ignore the subject and subsection? Not about stallguard or features, so here we go… 
You can have as many switches as you’d like, no software required. Just get “normally closed” switches and chain them together. If any one of those opens, you’ll trigger. I’m not sure what that would accomplish, but you’d get a redundant switch/endstop. I don’t know what you mean by “main” and “failsafe” though. What problem are you trying to solve? Maybe a new thread with some context would get us on the right track?
Well, you were the one who brought up the alternative (non-stall) solution, I was just asking about it.
Of course you don’t need to ignore anything, but most of all shouldn’t ignore the very message you’re replying to, you know. 
And I meant no disrespect, and I am in fact very impressed, and thankful, for your swift responses. 
Ah, that’s a good idea, at least if my main switches happen to be NC. Or if they’re NO then I suppose I can get other NO switches and connect them in parallel instead.
I (like the OP, I suppose) have had several situations where the print head has tried to move past one end or another, either because of an incorrect homing or because of the end stop switch failing or because the steps/mm were out of whack or who knows. I’d like to add some kind of end stop switches that are always active and which would detect such an event and make the printer stop trying to break itself.
If you want to have a switch that’s always monitored you could use a gcode_button, but it would require some effort to make it work. Something like Hall effect endstops combined with physical switches. It also wouldn’t trigger immediately because I believe gcode_buttons are added to the move queue, so it could take a couple seconds to trigger.
The emergency stop op bypasses the queue, so at least that would be more or less immediate.
It’s a good idea, thank you!
Sorry for the confusion, sounds like you got some ideas for this. Although, I have no idea about klipper compatibility with them, but it really sounds like some closed loop steppers(like,BTT S42B) would be helpful for you. They measure the actual distance travelled vs requested distance. So you can actually see it skip a step before it drifts so far as to hit an endstop. It really is amazing how well our printers can hang onto a position without any feedback at all after homing. Kevin was also playing with using angle sensors for feedback, that maybe worth digging into a bit… Some of the TMC drivers have encoder inputs to do this internally but I don’t know of any printer firm/software that supports it yet.