Could do with some help with sensorless homing on a CoreXY

deckingman

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 detection

G1 X-400 F3000; do a long X move at 3000mm/min
M574 X1 Y1 S1; put end stop switches back

then 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.3

Thanks in advance

Oh and the motors 59Ncm @2Amp which I normally run at 1800mA. Could that have bearing?

deckingman

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.

sigxcpu

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

deckingman

@sigxcpu Thanks for sharing. Nothing leaps out at me though.

dc42

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.

deckingman

@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

dc42

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.

deckingman

@dc42 Brilliant! Thanks David. Glad to know that this wasn't a case of senility on my part.️

deckingman

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 1000

M122 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

dc42

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

deckingman

@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.

deckingman

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.

dc42

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.

deckingman

@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.

deckingman

@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 maxima

G91 ; 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 U

G1 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 U

G1 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 V

G1 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 V

M584 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 absolute

M906 X1800 U1800 Y1800 V1800 Z1800 ; set motor currents back to defaults

M104 S0; set hot end temp back to zero

deckingman

Above post deleted - me being stupid.

Edit. Post restored, I'm still probably stupid but not for the reasons I thought.

deckingman

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.

wilriker

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 axis

this 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 P3

I think it needs to be done like this because parsing M584 does 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 to U and V.

At least something to try.

deckingman

@wilriker Thanks for that. It makes sense so I'll give it a try.

deckingman

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 Y

Then 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.....

deckingman

Latest update. Creating axis in the correct order seems to have fixed the end stop recognition issue. So this in config.g works

M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3;

All I'm left with now is that the A and B axes move diagonally using a single motor, rather than in X and Y using both motors. i.e Cartesian rather than CoreXY kinematics. So close....

wilriker

@deckingman What happens if you swap

M584 X0:3 Y1:4 Z2 U10 V11 A6 B9 E5:7:8 P3

by

M584 X0:3 Y1:4 Z2 A6 B9 U10 V11 E5:7:8 P3

(A and B defined before U and V)? Will this make the extruder gantry act as Cartesian and have the counter-weight gantry move correctly?

deckingman

@wilriker That's what had at first - see post one before my last timed at 10:41. I still had the Cartesian axis movement (for A and B) but also, the endstop switches weren't being acted on correctly.

Edit. The extruder gantry (U and V) still acted correctly as CoreXY.

2nd Edit It's kind of coming back to this thread https://forum.duet3d.com/topic/6677/corexyuvwa

Do you think making the axes W and A rather than A and B would help? It used to be necessary to create them in that order but I believe that later firmware doesn't care. Just wondering if there is something in the firmware left over from how it used to be that shouldn't be there.....

wilriker

@deckingman Honestly, I checked the source code again and I have no clue how an endstop is assigned to an axis at all. I found the code where the endstop is setup per axis but I have yet to find the place where it looks for a specific endstop for a given axis.

Anyway, while I am hunting this part down (and I have an idea where to look for) I have another question: I have something in the back of my mind, but not sure anymore. Do you switch at any point (after homing) to CoreXY mode? Also once you assigned all three steppers to X/Y do they move correctly i.e. A/B also act like CoreXY kinematics?

JoergS5

@wilriker An endstop code is in Movement\Kinematics\CoreBaseKinematics.cpp

If the drive is shared, in CoreXYKinematics.cpp the method DriveIsShared returns true, which is evaluated in the CoreBase file.

The OnHomingSwitchTriggered method is called from Movement\DDA.cpp line 1595 in the v2-dev branch. It is called when an endstop is hit.