Could do with some help with sensorless homing on a CoreXY
-
I now have my 6th and 7th axes installed to my CoreXYUV. Not sure what to call these other axes - they do the opposite of X and Y so maybe 1/X and 1/Y or X^-1 and Y^-1?
All gantries are moving in the correct directions when commanded to do so but I'm trying to use stall detection to home these additional axes independently of XYUV without much luck. Has anyone succeeded in getting stall detection/sensor less homing to work on a CoreXY and if so, could you share your settings please?
Alternatively, take a gander of what I've tacked on to the beginning of my homex.g which is as follows, and tell me what I've got wrong.....
G91; relative
M584 X6 Y9 ; temporarily map drives 6 and 9 to XY
M906 X200 Y200; set motor currents low
M915 P6:9 S0 R0; configure stall detection
M574 X1 Y1 S3; configure end stop switches for stall detectionG1 X-400 F3000; do a long X move at 3000mm/min
M574 X1 Y1 S1; put end stop switches backthen I remap drives and continue with "normal" X and U homing which all works as it should.
Everything moves as it should but when the axis reaches the hard stop, it continues to grind away and the belts jump teeth. If I set the motor current any lower the gantry won't move. Any higher and the tooth jumping thing gets more violent and is likely to do physical damage. It doesn't seem to matter what I set the S parameter to. The Wiki says values less that -10 not recommended but I've gone lower than this with no change to the behaviour.
The drivers 6 and 9 are on the Duex5 (obviously).
Software info as follows:
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.0 or 1.01 + DueX5
Firmware Version: 2.01(RTOS) (2018-07-26b2)
Web Interface Version: 1.22.3Thanks in advance
Oh and the motors 59Ncm @2Amp which I normally run at 1800mA. Could that have bearing?
-
Additional info if this helps. Just ran M122 after homing x as per the above code.
Drivers 6 and 9 show SG min/max of 0/0. I'm sure that must mean something to someone cleverer than I.
Further edit - on close inspection, the belts don't jump as I thought - it's just the motors vibrating loudly and violently.
-
This is my homex.g (Y is the same). My problems were that it was detecting stall upon starting b/c of high acceleration and the solution was to reduce acceleration during homing (hence the set_accel.g macro to restore).
Not your problem, but maybe you get some inspiration.M400 ; make sure everything has stopped before we make changes M915 P0:1 S3 F0 R0 ; configure stall detection M574 X1 Y1 S3 ; set endstops to use motor stall M913 X50 Y50 ; reduce motor current to 50% to prevent belts slipping M201 X500 ; reduce acceleration to avoid false triggering G91 ; use relative positioning ; X or Y is homed at this point, now home the other axis G1 S1 X-325 F4000 ; move towards axis minimum G1 X22 ; move away from home M400 ; make sure everything has stopped before we reset the motor currents M913 X100 Y100 ; motor currents back to 100% G90 ; back to absolute positioning G92 X0 M574 X1 Y1 S1 M98 Pset_accel.g ; restore acceleration values
-
@sigxcpu Thanks for sharing. Nothing leaps out at me though.
-
Check that the homing move speed and steps/mm together give a high enough full steps per second speed to be above the stall detection threshold steps/second.
You could call the additional axes A and B instead of mapping the motors to X and Y.
-
@dc42 Thanks.
My steps per mm and pulley are exactly as the example in the wiki which indicates that the speed should be at least 2400mm/min and I'm using 3000. Just tried 4,000 to no avail.
On the drive mapping, once homing is complete, I need to map these axes to X and Y in any case. So for printing it becomes M584 X0:3:6 Y1:4:9 Z2 E5:7:8
-
I've just checked the code, and stall detection isn't handled properly for CoreXYUV kinematics. When you home X, it only checks for a stall on the X motor, and when you home Y it only checks for a stall on the Y motor. I'll fix this in the next build. If you home X and Y simultaneously, it ought to stop the movement when either motor stalls.
Meanwhile, you could switch the machine to CoreXY mode, home the new axes, then switch to CoreXYUV and home the rest.
-
@dc42 Brilliant! Thanks David. Glad to know that this wasn't a case of senility on my part.☺️
-
OK, I've tried temporarily setting CoreXY mode but unfortunately I still don't seem to be getting any detection of motor stall. I do now get an error message saying that homing has failed which is a step in the right direction. I also tried moving X and Y simultaneously but when X reaches the physical stop both motors simply vibrate alarmingly until the remainder of the move completes.
I've tried reducing acceleration and increasing speed. Current homex.g now looks like this:
M669 K1; coreXY mode - reason temporary firmware bug
G91; relative
M584 X6 Y9; temporarily map dynamic load gantry steppers to X and Y
M906 X200 Y200; reduce motor currents
M201 X400 Y400; reduce accelerations
M915 P6:9 S0 R0; configure stall detection
M574 X1 Y1 S3; configure end stop switch for stall detection
G1 X-400 F4000; do a long slow move to x min - tried doing G1 X-400 Y-400 F400 but no difference
M574 X1 S1; configure end stop switch back to where it was
M669 K8 ; put kinematics back to CoreXYUV
M201 X1000 Y1000 ; put accelerations back to 1000M122 reports SG values for D6 and D9 but they are highly variable. After the last homeX I have SG min/max of 0/52 for drive 6 and 0/46 for drive 9.
If it helps, motor specs as follows:
Voltage (VOC) 2.80
Amps/Phase (2.00
Resistance/Phase (Ohms @25degC) 1.4+_ 10%
Inductance/Phase(mH@1KHz) 3.00+_20%
Holding Torque (Nm) 0.59
Step angle 1.8
Rotor Inertia (g-cm) 82.00
-
From the datasheet:
Due to the dependency of the stallGuard2 value SG from motor-specific characteristics and application specific demands on load and velocity the easiest way to tune the stallGuard2 threshold SGT for a specific motor type and operating conditions is interactive tuning in the actual application.
The procedure is:- Operate the motor at a reasonable velocity for your application and monitor SG.
- Apply slowly increasing mechanical load to the motor. If the motor stalls before SG reaches zero, decrease SGT. If SG reaches zero before the motor stalls, increase SGT. A good SGT starting value is zero. SGT is signed, so it can have negative or positive values.
- The optimum setting is reached when SG is between 0 and 400 at increasing load shortly before the motor stalls, and SG increases by 100 or more without load. SGT in most cases can be tuned together with the motion velocity in a way that SG goes to zero when the motor stalls and the stall output SG_TST is asserted. This indicates that a step has been lost.
I'm wondering whether the back emf of those motors is too low at the very low motor current you are using, but I understand why you don't want to use a higher current.
HTH David
-
@dc42 said in Could do with some help with sensorless homing on a CoreXY:
................................
I'm wondering whether the back emf of those motors is too low at the very low motor current you are using, but I understand why you don't want to use a higher current.HTH David
Hmm. Well I think there is a real risk of some physical damage happening if I try and increase the current.
Maybe sensor less homing isn't an option with these motors and I have to come up with a plan B.
Any ideas? I do have a couple of spare estop connectors on the Duex5 and I could fit a couple of switches easy enough.
-
As a temporary solution, I've made use of M291 in my homing files to prompt me to move the load cancelling gantry to the appropriate position. Along with reducing motor currents, this will hopefully be enough to prevent anything nasty happening - at least until I can come up with a better plan.
-
You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.
-
@dc42 said in Could do with some help with sensorless homing on a CoreXY:
You could define the two additional motors as axes A and B while homing them, allowing you to use endstop inputs 5 and 6 aka E2 and E3 assuming there is no W axis.
Thanks. I'll give that a go when I get chance. E2 and E3 are currently used for axes maxima and another switch to trigger an emergency stop, but I can move them to E4 and E5 easily enough.
-
@dc42 OK, so I've hooked up a couple of switches but still not having a great deal of success. I get movement in the X direction for axis A but no movement in the Y direction for axis B. Then after "attempting" to home A and B, my homeall.g file then homes XYU and V as it has always done, but after these have been homed, no movement in the X direction is possible for any of the gantries. Homeall. g normally moves to the centre of the bed for Z probing but after doing XYU and V., it only moves in the Y direction. However, movement in Y works fine for all 3 gantries.
It's likely that I have missed or configured something incorrectly but after a few hours, I still can't find my mistake.
My annotated homeall.g is as follows:
; homeall.g
; called to home all axes
; Use This for Dynamic Load Gantry - mapping is different*; start by warming the hot end so that any oozed filamnt is molten
TO; select a tool - any one will do
M104 S140; heat to 140 but don't wait;********** COMMANDS FROM HERE ADDED FOR UPPERMOST (3RD) GANTRY ********
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with
M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents
M584 A6 B9 P7; create A and B axes for upper gantry
M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axis
M350 A16 B16 ; configure microstepping for A and B
M92 A80 B80 ; configure steps per mm for A and B
M566 A600 B600; inst speed change
M203 A50000 B50000; max speed
M201 A1000 B1000; accel
M208 A0 B0 S1; axes minima
M208 A380 B380 S0 axes maximaG91 ; set to use relative coordinates
G1 A-380 B-380 F4800 S1 ; move fairly quickly until one of other end stop switches triggers
G1 A-380 S1 ; course home A
G1 A10 F600 ; move back a few mm slowly
G1 A-380 F360 S1 ; fine home A
G1 B-380 F4800 S1; course home B
G1 B10 F600 ; move back a few mm
G1 B-380 F360 S1 ; fine home B
; *****DURING THE ABOVE, THERE IS "A" axis MOVEMENT IN THE X DIRECTION
; *****BUT NO "B" axis MOVEMENT IN THE Y DIRECTION
; ***** AND THE A(X) AXIS SEEMS TO BE IS LOOKING FOR THE B(Y) ENDSTOP; END OF ADDITIONAL COMMANDS*
M584 X0 U3 Y1 V4 P5; temporarily map drives to U and V axes - have to map both axes even thought only U is being used due to both motors being employed per axis
G91 ; set to use relative coordinates
G1 Z5 F600 ; move bed down 5 mm
G1 X-380 U-380 Y-380 V-380 F4800 S1; move all 4 axes fairly quickly until one or other triggers a switch
G1 X-380 U-380 F4800 S1; now move just X and U fairly quickly left until one or other triggers a switch
G1 X-380 S1; course home X
G1 U-380 S1; course home UG1 X10 U10 F600 ; Go back a few mm
G1 X-380 U-380 F360 S1; Move slowly to X and U axis endstops once more and stop when one triggers
G1 X-380 F360 S1 ; fine home X
G1 U-380 F360 S1 ; fine home UG1 Y-380 V-380 F4800 S1; now move Y and V fairly quickly left until one or other triggers a switch
G1 Y-380 S1; course home Y
G1 V-380 S1; course home VG1 Y10 V10 F600; Go back a few mm
G1 Y-380 V-380 F360 S1; Move slowly to Y and V axis endstops once more and stop when one triggers
G1 Y-380 F360 S1 ; fine home Y
G1 V-380 F360 S1 ; fine home VM584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P7; add dynamic gantry to XY ; map all 3 gantries to X and Y
G90; set to absolute coordinates
; ******* FROM THIS POINT ON, NO MOVEMENT IN THE X DIRECTION IS POSSIBLE
; ******* JUST NOTHING HAPPENS WHEN ANY X MOVE IS ASKED FOR
; ******* THIS APPLIES TO ALL 3 GANTRIES
; ******* BUT Y DIRECTIONS MOVES WORK FINE FOR ALL 3 GANTRIES AS DOES Z
;******** THIS BEHAVIOUR PERSIST AFTER HOMING AND THE MACHINE HAS TO BE RESET.G1 X180 Y180 F12000; move all 3 gantries to more or less the centre of the bed
; **** AS STATED ABOVE, THE X DIRECTION COORDINATE NO LONGER HAPPENS
M109 S140 ; continue heating bed to 140 but this time wait
G30
G91 ;relative
G1 Z5 F300
G90 ; back to absoluteM906 X1800 U1800 Y1800 V1800 Z1800 ; set motor currents back to defaults
M104 S0; set hot end temp back to zero
-
Above post deleted - me being stupid.
Edit. Post restored, I'm still probably stupid but not for the reasons I thought.
-
Also tried sensor less homing as above with motor currents set to 500mA but still no stall detected. At a bit of a loss as to what to try next.
-
This is just a shot in the dark but it feels odd to me that
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with [...] M584 A6 B9 P7; create A and B axes for upper gantry M574 A1 B1 S1 ; create end stops E2 and E3 for the new A and B axisthis would work as intended. I mean the part where you first do the axes definition and then reassign drives to other axes and assume that E2 and E3 match to these axes. I looked into the source code and even though I did not understand everything I found I think you need to define the new axes in the right order in one command. Something like the following might be more correct:
M584 X0:3 Y1:4 A6 B9 Z2 U10 V11 E5:7:8 P3I think it needs to be done like this because parsing
M584does not really care about the letters being in strict XYZUVWABC order anymore but the order they are given is more or less responsible for the endstop-mapping. So in your current setup the endstops would be mapped toUandV.At least something to try.
-
@wilriker Thanks for that. It makes sense so I'll give it a try.
-
OK, so I've tried @wilriker's suggestion. Essentially, I've moved the creation of the A and B axes to config.g. So I have in config-g:
M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3;
followed by:
M574 Z0 S0 ; Define active low and unused microswitches
M574 X1 Y1 S1 ; Define active high microswitches
M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing the upper XY
M574 A1 B1 S1;Then I've set all the other axis related parameters for all 7 axes (M350, M92, M566, M203. M201 etc).
After which I remap drives thus:
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; Remap A and B to X and YThen I've simplified the start of homeall.g so that it starts with this:
M584 X0:3:6 Y1:4:9 Z2 U10 V11 E5:7:8 P3; make sure mapping is as per config.g to start with
M906 X400 U400 Y400 V400 Z1200 ; reduce motor currents
M584 A6 B9 P7 ; RE-Map A and B
G91 ; set to use relative coordinates
;G1 A-380 F4800 S1 ; course home X
;G1 A10 F600 ; move back a few mm slowly
;G1 A-380 F360 S1 ; fine home A
G1 B-380 F4800 S1; course home B
G1 B10 F600 ; move back a few mm
G1 B-380 F360 S1 ; fine home B
This has helped in as much as at the end of homing, all axes now move in both the X and Y directions. However, homing A and B does not work and I've figured out the reason why. Basically I get diagonal movement when asking for pure X or pure Y moves. This was masked in my earlier attempts at homing A and B because I started with a diagonal move in any case. I've now taken that out.
So it seems that when I create A and B in config.g, they are created as Cartesian axes and only move one motor, rather than CoreXY which requires both motors to be moved. Also, A (X) still seems to be looking at B(Y) end stop - actually I think (but can't be sure) that both axes look at the same end stop - I'll check that.
Late thought. I've just noticed that I create U and V before A and B so that might be the end stop issue. I'll swap and report back.....
