Stall detection and sensorless homing
-
Thanks, I've corrected it.
-
I updated to 1.20b6 last night and got sensorless working on X on my coreXY before finally getting in bed. I think I ended up at +2 on sensitivity for X while that didn't work for Y, which is when sleep decided it was boss.
I can't wait to get home today and play some more. If I can get sensorless working for X/Y and my precision piezo working for Z, I'll be ALL SET, for now.
-
What about accuracy? Do you think it will be possible to use sensorless homing for power recovery feature?
-
@fma:
What about accuracy? Do you think it will be possible to use sensorless homing for power recovery feature?
Not according to the limitations that David has set out in the Wiki https://www.duet3d.com/wiki/Stall_detection_and_sensorless_homing
-
I updated to 1.20b6 last night and got sensorless working on X on my coreXY before finally getting in bed. I think I ended up at +2 on sensitivity for X while that didn't work for Y, which is when sleep decided it was boss.
I can't wait to get home today and play some more. If I can get sensorless working for X/Y and my precision piezo working for Z, I'll be ALL SET, for now.
Sensor-less homing isn't something that I'd want to use personally but all the same, I'd be interested to know how you get on setting it up with a CoreXY. I'm just thinking of the fact that we don't actually have X and Y motors, rather delta a and delta b and both contribute to movement in the X and Y directions.
-
I suspect it works the same on corexy or delta, in that the firmware waits for a stall detect event to occur, rather than an endstop trigger, before stopping the motors and setting x=0 or y=0, whether its motor A or Motor B which stalls (or both) is probably irrelevant.
Speaking of both I wonder if this feature might be useful to do a bit of analysis on corexy calibration, when you hit the buffers, so to speak at -x both A and B motors should stall simultaneously. If they do not does that indicate a discrepancy in A and B belt tension? Since a move towards -x (or any other pure x or y direction change) requires both motors to turn at the same rate.
-
I suspect it works the same on corexy or delta, in that the firmware waits for a stall detect event to occur, rather than an endstop trigger, before stopping the motors and setting x=0 or y=0, whether its motor A or Motor B which stalls (or both) is probably irrelevant.
Speaking of both I wonder if this feature might be useful to do a bit of analysis on corexy calibration, when you hit the buffers, so to speak at -x both A and B motors should stall simultaneously. If they do not does that indicate a discrepancy in A and B belt tension? Since a move towards -x (or any other pure x or y direction change) requires both motors to turn at the same rate.
I'd say that may strongly depend on variations between individual motors. One being a bit hotter than the other, longer wires/worse connection or just some difference in coil resistance could throw stallguard off a bit…
-
I have both X/Y working smoothly and consistently. It's amazing what you can do when you're awake/alert.
Here's my X homing test macro based on David's sample in the wiki:
M400 ; make sure everything has stopped before we make changes
M574 X1 Y1 S3 ; set endstops to use motor stall
M913 X50 Y50 Z50 ; drop motor currents to 50%
M915 X Y S3 R0 F0 ; set X and Y to sensitivity 3, do nothing when stall, unfiltered
G91 ; use relative positioning
G1 S1 X-300 F4000 ; move left 300mm, stopping at the endstop
G1 X30 ; move away from end
G90 ; back to absolute positioning
M400 ; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 Z100 ; motor currents back to 100%
M574 X1 S0 ; Define active low and unused microswitches
M574 Y1 Z1 S1 ; Define active low and unused microswitchesWell done David, seriously, I love it.
-
I'm making some sensorless homing tests, and it works great!
However, I'm using a CoreXY, and unlike sensor homing, when I launch a diagonal move, with something like:
G1 X325 Y325 F3600
both motors stop as soon as stall is detected on one of them. Is it what the code does, or is it because stall of one motor influence the other? In the first case, could it be possible to have the same behavior as sensor homing, and in the second case, what can I do to fix that?
Thanks.
-
My bad! I forgot the specific procedure on the CoreXY homing…
Here is my setup:
M400 ; make sure everything has stopped before we make changes M574 X2 Y2 S3 ; set endstops to use motor stall M913 X50 Y50 ; drop motor currents to 50% M915 X Y S2 R0 F0 ; set X and Y to sensitivity 2, do nothing when stall, unfiltered G91 ; use relative positioning G1 Z10 F1200 ; lift Z G1 S1 X325 Y325 F3600 ; move right/back 325mm, stopping at the endstop G1 X-5 Y-5 ; move away from end M915 X Y S-2 R0 F0 ; increase sensitivity G1 S1 X325 F3600 ; move right 325mm, stopping at the endstop G1 S1 Y325 F3600 ; move back 325mm, stopping at the endstop G1 X-5 Y-5 ; move away from end G1 Z-10 F1200 ; lower Z M400 ; make sure everything has stopped before we reset the motor currents G90 ; back to absolute positioning M913 X100 Y100 ; motor currents back to 100% M574 X1 Y1 S1 ; define active low microswitchesAs you can see, I changed the sensitivity, because I noticed the stall detection is not the same when both motors run, or only one. With this settings, the homing is very smooth, no noise when hitting walls.
-
Mmm, this is not that simple. There are very large variations between motors cold and motors hot. So I have to decrease the sensitivity, or I get false detection. But then, the choc is more important when hitting walls
I will try to change (reduce) the motor current between the first homing (diagonally, -> only 1 motor running), and the second and third (X or Y -> 2 motors running)…
David, I'm wondering: during a X or Y move, do you wait for both motors to stall to consider at endstop, or any of them?
-
I wasn't expecting CoreXY users to use sensorless homing. The way it will work at present is that during the initial G1 X Y move, if either motor stalls then the whole move will be stopped. In the subsequent G1 X move, only the X motor will be monitored, and in the G1 Y move only the Y motor will be monitored. Obviously it would make sense to monitor both motors for all three moves.
I think it's the case that the lower you set the M915 S parameter, the more sensitive the stall detection will be to temperature.
-
Do you plan to monitor both motors in a future release?
-
If it's easy to do then I'll include it in the next beta.
-
Thanks!
-
I did give this a try on my corexy yesterday I used your x homing gcode Frédéric, and modified it for y as well. I had to turn my sensitivity up to 7 for x and 8 for y but it did work. Not very reliably sometimes I got false triggers, if I went as high as 13 on sensitivity it crashed the end of the travel pretty hard and didn't trigger.
So cool idea but I'm sticking with endstops for now.
-
I wasn't expecting CoreXY users to use sensorless homing.
Thanks for doing this David it is quite a nice feature to play with, but if a corexy is a 2-motors-linked-kinematic and a delta is 3-motors-linked, can this be used for deltas? Or is it actually easier as there is one endstop per tower and one motor it controls?
I wouldn't use it on the kossel Xl as my optical endstops are very accurate probably better than the 4 steps resolution. But I'd like to try making a delta from a tube which was discussed on reprap, and an endstop-less scheme appeals.
-
Yes deltas are easier because each tower has one motor and one endstop. I had it working well on my delta, although I wouldn't rely on it without doing an auto calibration cycle after homing.
For sensorless homing on a delta, I suggest putting the motors at the top and making the physical endstop adjustable with a range of at least 4 full steps. That way, the belt distance between the motor pulley and the carriage when homed will be small, so thermal expansion shouldn't change the homed motor position by as much as a full step. If it turns out that the homing position is on the cusp between full steps, you can adjust the physical endstop position to avoid that.
Just about any type of endstop switch should have resolution way better than 1 full step.
-
This might be a particularly helpful feature for CoreXY printers that plan to implement parked effectors!
-
Hmm, could we use stall detection as a z probe? Or would it be too aggressive?
