Stall Detection Only Giving False Readings No Real Readings
punamenon last edited by punamenon
I have got sensor less homing on X and Y functioning without error using a stall detection threshold of 3 (M915 S3 ). During a print, if I manually force the X-carriage away from the part the printer continues printing in the air as if nothing had happened.
I have changed the stall detection threshold to 0 (M915 S0 ). During a print, this new value yields many false readings which reset the printer. However, if I manually force the X-carriage away from the part the printer still continues printing in the air as if nothing had happened. Until another false reading occurs.
Here is a video: https://youtu.be/oSX50_gS-Bc
Other possibly pertinent info:
the printer runs on 24v
motor current is set to 200 mA
acceleration is set at 300 mm/s^2
maximum instantaneous speed change is set at 600 mm/min
no technical data is available for the stepper motors
How can I get this working correctly? Is this a common problem? How many of you have stall detection working? Do you have different values for stall detection vs sensorless homing?
Why are you blocking the movement of the carriage?
punamenon last edited by
@fcwilt It is to simulate a collision with a part. Or any other user error which might cause the print head to skip steps. When this happens the layers will become misaligned and ruins the print. With the stallguard feature of the Trinamic drivers, this "problem" is solved. I know it's kind of stupid, but I'm just trying to match the "features" on a Prusa.
What are the compete set of parameter values you are using for M915?
punamenon last edited by
@fcwilt When the printer is running sensorless auto homing: M915 X Y S3 R0 F0
In the video the printer is printing: M915 X Y S0 R3 F1
I've tried a lot of combinations of settings. None work. I think the core of my problem is the S value. When it is set to 0, I get false readings constantly. When it is set to 1, I get no false readings, but also it does not trigger when I stall the head by hand. This value must be an integer. Therefore, I cannot fine tune it any further (i.e. I can't set a value of 0.5).
While writing this response I just set everything to M915 X Y S1 R0 F0 Sensorless homing works, and it prints without false readings. Once in a while if I just kind of apply pressure on the X-carriage (instead of forcing it to move, and audibly skip the motor) I can get it to trigger and re-home.
I just don't understand why the sensorless homing works perfectly at an S value of 3, and yet triggering while printing doesn't really even work at an S value of 1. I even tried putting an immovable clamp on the X-axis rail. This should be the exact same physically as hitting the limit when homing. What happened? The X-carriage hit the clamp, the motor made a skipping noise, and it just kept on printing like nothing had happened. It doesn't make sense, unless there is something buried in the firmware which causes the Trinamic Stallguard feature to behave differently when printing vs when homing.
I have no idea.
Perhaps it is the same as the situation when you have end stop switches.
They are checked when homing but not during normal moves.
Phaedrux last edited by
I assume you've already read through this:
There are a lot of caveats to stall detection. It depends a lot on the motors, temperature, speeds, current, etc. The reason it works so well on the Prusa is that they have chosen hardware that all works well together and tuned it from the start. It may be that your motors are not very suitable.
I have a corexy and it's even harder to get it working well because you have two motors working together. I got stall detection working to home z but it took a lot of trial and error. I gave up on it, since I don't think it is particularly useful, but I understand your purpose here is to try and reach feature parity with the prusa. Hopefully someone that has gotten it working will see this and be able to help out. Have you searched the forum? I know there have been other threads about getting it tuned and working.
Thanks for that link. I had not seen it before.
There are a lot of caveats to be sure.