SOLVED Stall detection CoreXY not working?
Chriss last edited by Chriss
I'm started today with the wireing of my RatRig CoreXY and my Duet3.
I do not have any hardware switch around so I want to give the stall detection a try. I think that this is worse to time to play a bit with it and learn something new.
I used the configtool to generate a config and did only a view tweaks.
I searched a bit in the forum and I learned that some people had various problems with that feature. So I tried to learn from them and borrowed some snipits from there config. (homex.g)
Long story short: The stall detection does not detect on X when it hits the frame. I think that I have seen it working while I followed the guide to make sure that the drives are configured correctly. But I would not bet on that.
I read some old posts that the stall detection works only while printing g-code, is that true and still valid? I can stop my tests if that is still the case than.
; Configuration file for Duet 3 (firmware version 3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.1.1 on Thu Jun 04 2020 17:41:46 GMT+0200 (Central European Summer Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Duet 3" ; set printer name M669 K1 ; select CoreXY mode ; Drives M569 P0.1 S0 ; physical drive 0.1 goes forwards M569 P0.2 S0 ; physical drive 0.2 goes forwards M569 P0.5 S1 ; physical drive 0.5 goes forwards M584 X0.2 Y0.1 Z0.5 ; set drive mapping M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation M92 X80.00 Y80.00 Z4000.00 ; set steps per mm M566 X900.00 Y900.00 Z12.00 ; set maximum instantaneous speed changes (mm/min) M203 X6000.00 Y6000.00 Z180.00 ; set maximum speeds (mm/min) M201 X500.00 Y500.00 Z20.00 ; set accelerations (mm/s^2) M906 X800 Y800 Z800 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X12 Y13 Z0 S1 ; set axis minima M208 X400 Y400 Z400 S0 ; set axis maxima ; Endstops M574 X1 S3 ; configure sensorless endstop for low end on X M574 Y1 S3 ; configure sensorless endstop for low end on Y M574 Z1 S3 ; configure sensorless endstop for low end on Z ; Z-Probe M558 P0 H5 F120 T6000 ; disable Z probe but set dive height, probe speed and travel speed M557 X27:215 Y28:195 S20 ; define mesh grid ; Heaters M308 S0 P"1.temp0" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin 1.temp0 M950 H0 C"1.out0" T0 ; create bed heater output on 1.out0 and map it to sensor 0 M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C ; Fans ; Tools ; Custom settings are not defined ; Miscellaneous M501 ; load saved parameters from non-volatile memory M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss
;;;;;;;;;;;;;;;;;; M400 ; make sure everything has stopped before we make changes M915 X S0 F0 R1 ; increase stall sensitivity for endstop homing M913 X50 ; reduce motor current to 50% to prevent belts slipping ;;;;;;;;;;;;;;;;;; G91 ; relative positioning ;G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-417 F1800 ; move quickly to X axis endstop and stop there (first pass) G1 X5 F6000 ; go back a few mm G1 H1 X-417 F360 ; move slowly to X axis endstop once more (second pass) ;G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning ;;;;;;;;;;;;;;;;;; M400 ; make sure everything has stopped before we reset the motor currents M913 X100 ; motor currents back to normal M915 X S12 F1 R1 ; Increase StallGuard thresold to prevent false readings ;;;;;;;;;;;;;;;;;;;;
So what did I do wrong here?
This post is deleted!
@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
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.
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
oliof last edited by
I may be working on my V Core Pro again this weekend and can share my stall detection setup which works.
@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.
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.
deckingman last edited by
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 last edited by
@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 last edited by Chriss
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.
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.