turning stall detection on only when homing?
I was reading your wiki about how to setup stall detection. I need it to home all my axis as I did not design in any way to mount limit switches. The page says it's sensitive to acceleration if I get my parameters wrong
What if I only turned it on in my homing macros, and ensure it's off while printing? Then my print will never cause false detection, right?
I understand this is a bit dangerous if my print somehow messes up, I don't think it'll snap my belts so I'm not too worried.
Phaedrux last edited by
Stall detection endstops are only active during a homing move anyway (G1 S1). I think what you're quoting is in regards to using stall detection during a print, which is separate.
As long as the printer is homed correctly before starting a print, and your mechanics move accurately during the print, the firmware will keep it from exceeding the set axis limits. Endstops won't trigger anything if they are hit during a print.
I think my Ultimaker would kill a print if the limit switches are hit, for safety or just not wasting filament, that's what's making me think it mattered during print. If the Duet works differently, then I'll just keep that in mind, this isn't a public use printer. Thanks. Layer shift recovery is a stretch goal.
Here's a weird question:
That the stopper shaft collars are set in position while the printer is completely off. This should mean that the magnetic forces of the steppers are technically in "full step" position already, correct?
The X and Y are on belts, the two Z are on leadscrews. The limits on the X and Y are set at the end where there's minimal distance between the carriage and the belt, so that when the collars are hit, there's minimum stretching of the belt before the stall detection triggers. But, I am aware that there's going to be some microscopic streching. (the ball bearings are preloaded with spring tension so I don't expect my rods to shift, I am aware of the possibility, hence the preloading)
This leads to my next weird question: Should I disable microstepping during homing? Should I disable interpolation? For the sake of the most consistent repeatability, for stuff like power-loss or layer shift recovery.
My own guess is no, but I'd like to confirm.
Phaedrux last edited by
Should I disable microstepping during homing?
I would say no, though I don't really understand the preamble to your question.
My understanding is that stalls will occur at the nearest full step anyway. The amount of movement for a single step is going to be minimal anyway. If repeatability and accuracy of homing is of paramount importance, use endstop switches instead.
Alright thanks for all your help. I spent the day thinking about it and I think I failed to realize what I am truly worried about is the leadscrew backlash and the fact that I have two leadscrews for the Z axis. I realized the load on the motor would actually lower for a very brief moment while the thread is disengaged, and then shoot way up when the thread re-engages. I also don't know how two motors in series would generate back-EMF when one motor hits the endstop before another.
Today I installed my X and Y motors and did some tests. I found out that the trick to getting reliable stall detection during homing is to lower the acceleration 100, like , and use a faster travel speed, like F3000. What I noticed was without lowering the acceleration, using a high F parameter during the move was causing only a twitch of the motor. This was the false stall detection I was trying to avoid.
I have taken the acceleration parameters (and other settings) out of config.g and placed them into a "steppersettings.g" file, so I can lower the acceleration during the homing macros, and then restore it. Since config.g and homing___.g both call the same steppersettings.g file, I wouldn't make a mistake when I need to change the global acceleration parameters.
I'm happy with the progress I've made today.
I also spent some time 3D modeling a mount for a limit switch just in case I need to add one. Once I finish the whole printer, I'll do a Z repeatability test and see if I need to use a limit switch or just use stall detect.
Phaedrux last edited by Phaedrux
I found out that the trick to getting reliable stall detection during homing is to lower the acceleration 100, like , and use a faster travel speed, like F3000.
That matches my experience and that of others as well. High acceleration moves are perfect for triggering a stall detect.
placed them into a "steppersettings.g" file
I do something similar for my Z axis speed settings. I have a few different macros with the speed parameters in it for normal operation at startup for jogging, homing, and printing.
Using macros in this way to parameterize the firmware can make it a little easier if you end up having different settings for lots of situations. Forgetting to return a value back to normal can cause problems and can be very hard to track down. Motor currents for example. So having a macro to call to set the settings and a single place to edit them can be a big help.
I'll do a Z repeatability test and see if I need to use a limit switch or just use stall detect.
Stall detection for the Z axis only really works with a single motor. So if you're currently using two wired in series using the Za and Zb connectors you'll have a very hard time with it. A simple switch, or a Z probe is a much better option in that case.
A single motor, 0.9 degree preferably, high steps per mm, low acceleration, high travel speed, can work fairly well, but then you run into issues of the lead screws having quite a bit of rotational momentum, which can cause some over rotation at the stop (high speed to detect, and then sudden stop, low acceleration so higher dive height). Additionally, the sensitivity threshold is sensitive to motor temperature. So a successful homing after a cold power on, and homing after it's been powered a while may false positive too easily.
Rn Action to take on detecting a stall from any of these drivers: 0 = no action (default), 1 = just log it, 2 = pause print, 3 = pause print, execute /sys/rehome.g, and resume print
So the default action is to do nothing when a stall is detected. But stall-detection endstops will still work. So if you only use stall detection for endstops, you do not need two different sets of stall settings.