Stall detection CoreXY not working?

JoergS5

@Chriss I read a bit the documentation about stall detection and compared with your configuration, and have the following ideas for CoreXY (but I'm not an expert, they are just ideas):

the long belt makes it difficult to detect stall, so I would use higher current (if the stepper allows it) and not limit M913 during the test. Currently it uses only 400 mA
both steppers should be configured and with the same values. At homing both endstops can be reached first
I would set back a longer distance at G1 X5, so the steppers can accelerate a longer distance. With X10 it reaches about maximum speed
the parameter R1 im M915 seems suspicious to me, maybe it only logs, I would use the R0 default

Phaedrux

@Chriss said in Stall detection CoreXY not working?:

G1 H1 X-417 F1800

This may not be fast enough to trigger a stall.

The motor speeds during homing moves (G1 moves with S1 parameter) must be higher than the full steps/second threshold that you set in the stall detection parameters. For example, if you use the default threshold of 200 full steps/sec and at x16 microstepping you have 80 steps/mm , then the minimum homing speed is (200 * 16 / 80) = 40mm/sec = 2400mm/min. So your homing moves must have an F parameter greater than 2400. The standard homing files generated by configtool do a fast homing, then back off by a few mm, then a slow fine homing. You won't be able to do a slow fine homing if you are using sensorless homing.

https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing#Section_Limitations

Chriss

@Phaedrux @JoergS5
Thank you guys very much! You guided me into the right direction! The stall detection works now. At least is there a detection now and it seems to me that the detection is at the same point.

Here is my current setup which seems to work right now:

; homex.g
; called to home the X axis
;

M400                    ; make sure everything has stopped before we make changes
M915 X S3 F0			; Stall detection: https://duet3d.dozuki.com/Wiki/Gcode#Section_M915_Configure_motor_stall_detection
G91						;
G1 H1 X-420 F2400		; Test the endstop (F2400 to be fast enough for detection)
G1 X50 F6000       		; go back a few mm
G1 H1 X-55 F2400		; Do it one more time
G1 X79 F6000			; Move away from the end stop
G90               ; absolute positioning
M400                      	; make sure everything has stopped

Cheers, Chriss

oliof

I may be working on my V Core Pro again this weekend and can share my stall detection setup which works.

Chriss

@oliof said in Stall detection CoreXY not working?:

Would be nice.... I'm not so unhappy with my current setup but more input is always appreciated!

Cheers, Chriss

JoergS5

@Chriss Nice that it works now.

I still have doubts whether I would like to use stall detection myself, because it does put a certain amount of jerk on the construction, and I don't really know if this doesn't de-calibrate something (e.g. loosen screws). But maybe one can make a construction where the movement doesn't go towards the consctruction directly, but something which is decoupled from the construction.

Chriss

@JoergS5

Fully agree! I'm absolutely not convinced that this is a very good concept. Do not get me wrong here, I like the idea to detect a mechanical block by the electronic, that is very, very smart. On the other hand is there a print head with 393g plus bltouch which impacts the frame at F2400, that makes me a bit nervous, to be honest.

I'm more and more convinced that this is a temporary solution till the end switches arrive at my desk.

I do not think that you can decouple the impact. I think that the detection will not work any more when you soften the impact by a spring or something like that. The sensitivity is the key here.

Cheers, Chriss

deckingman

I gave up on trying to get it to work with my CoreXYUVAB. It's probably because my lightest gantry has a moving mass of around 2Kgs so I was never happy about slamming that mass against the frame other than by using greatly reduced motor current and slow speed. The only reason I tried it was that at the time, there was a firmware limitation that prevented me from using switches on the AB gantry. That was fixed long ago and switches are cheap and reliable (and not sensitive to motor/driver temperature which stall detection is).

mrehorstdmd

@Chriss Now that you have it working, it would be interesting to see what the precision is like. If you run a print that rehomes X and Y at each layer change (custom gcode in the slicer), the print quality will reveal the precision. I recently ran a similar test using optical endstops in my printer and found it very precise.

Chriss

@deckingman
I understand that you gave up. It seems not very reliable to me, at least with the current setup. I hear that that the motor skips steps when it reaches the mechanical end. That happens 3-5 out of 10 times. I guess that I can solve that with some tuning. But I'm not sure that this is worth the time.

@mrehorstdmd
That would require a full working printer and my is at least 20 hours build time away of that. I have no bed at the moment, one of three bed motors are missing. No fan is spinning and the bltouch lays on top of my num block on my keyboard.
But sure, I can make that test as soon as I can make the first test prints. But here is at least one limitation here. The head hits more the belt than the holder of X, that would make it very inaccurate, I guess. But I can put a solid peace of plastic to make the point of impact more solid.

Cheers, Chriss