RRF3 Homing Issues

smoki3

I think this is the same issue I mentioned in the RRF 3.0 thread.
I also happens with stall detection.

gtj0

I am completely and totally confused.
I don't see how anyone with a CoreXY can home their machines at all.

It all seems to be related to what happens when the XY axes are already homed. Homing again puts both in this weird state where I either get "Homing failed", "Insufficient axes homed" or " Code has been cancelled".

If you have a Duet3 CoreXY that works, can you share your homing files and maybe your endstop configurations?

Nuramori

@gtj0 I had to change it to make sure it backs off of the endstops first, since the issue seems to be that it will error out if it's too close. Here are my files. While they work, I still at times will get the error. A few tries will eventually get it to "home", or worst case I disable the motors and manually move it away a bit. I also had to slow down the speed of approach to the endstops.

I have a BLV cube, so the Y axis is a max, not a min, fyi...

; homex.g
; called to home the X axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G1 H1 X-355 F4000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 Y5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G90 ; absolute positioning

; homey.g
; called to home the Y axis
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 Y355 F4000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F4000 ; go back a few mm
G1 H1 Y355 F360 ; move slowly to Y axis endstop once more (second pass)
G90 ; absolute positioning

; homez.g
; called to home the Z axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X162.5 Y162.5 F6000 ; go to first probe point
G30 ; home Z by probing the bed

G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning

; homeall.g
; called to home all axes
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 X-355 Y355 F4000 ; move quickly to X or Y endstop and stop there (first pass)
G1 H1 X-355 ; home X axis
G1 H1 Y355 ; home Y axis
G1 H2 X5 Y-5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G1 H1 Y355 F360 ; then move slowly to Y axis endstop
G90 ; absolute positioning
G1 X152 Y166.4 F4000 ; go to first bed probe point and home Z
G30 ; home Z by probing the bed
G32 S2

G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning

gtj0

@Nuramori said in RRF3 Homing Issues:

@gtj0 I had to change it to make sure it backs off of the endstops first, since the issue seems to be that it will error out if it's too close. Here are my files. While they work, I still at times will get the error. A few tries will eventually get it to "home", or worst case I disable the motors and manually move it away a bit. I also had to slow down the speed of approach to the endstops.

Yeah that's exactly the same behavior I see. Thanks for confirming I'm not crazy.

smoki3

I am on duet2wifi, but the issue sounds equal

gtj0

@smoki3 Yeah I had the same issue on my Duet2 so it's not the boards.

T3P3Tony

@gtj0

My home x:

G91 			; use relative positioning

G1 S2 X3 Y3 F10000		; move X away a little so the switch is not pressed
M98 P"homey.g"			; Home Y

;M400 			; make sure everything has stopped before we make changes
G4 P100			; wait 400ms

M913 X25 Y25 		; drop motor currents to 25%

G1 S2 Z3 F5000		; lift Z 3mm
G1 S1 X-400 F6000 	; move left 400mm, stopping at the endstop
G1 S2 X2 Y2 F6000       ;move away for second pass
G4 P500			; wait 500msec
G1 S1 X-300 F300	; (second pass)
G1 S2 X2 Y2 F6000       ; move away from end
G1 S2 Z-3 F1200		; lower Z
G90 			; back to absolute positioning

;M400 			; make sure everything has stopped before we reset the motor currents
G4 P100			; wait 400ms
M913 X100 Y100 		; motor currents back to 100%

Home Y:

G91 			; use relative positioning

G1 S2 X3 Y3 F10000		; ensure X is clear
G1 S2 X3 Y-3 F10000		; move Y away a little so the switch is not pressed

;M400 			; make sure everything has stopped before we make changes
G4 P100

M913 X20 Y20 		; drop motor currents to 20%


G1 S2 Z3 F5000		; lift Z 3mm
G1 S1 Y-400 F5000 	; move to the front 400mm, stopping at the endstop
G1 S2 X2 Y-2 F5000      ;move away for second pass
G4 P500			; wait 500msec
G1 S1 Y-300 F300	; (second pass)
G1 S2 X2 Y-2 F6000
G1 S2 Z-3 F1200		; lower Z
G90 			; back to absolute positioning

;M400 			; make sure everything has stopped before we reset the motor currents
G4 P100			; wait 400ms
M913 X100 Y100 		; motor currents back to 100%

Notes:

The M400s\G4s are from an issue with old DSF that i think is fixed but i have just not removed them.
Home X always calls home Y first due to an issue with X movement if the tool pickup head is at Y max on the toolchanger.
Home Y moves X a bit first because otherwise if X is at its minimum position it can crash on the switch mount (will change this in a future design).

With that in mind I don't experience the issues you are seeing with homing failed if the switches are already triggered however if multiple people are seeing this on RRF 3 on Duet 2 and 3 then its something we need to look at.

gtj0

Thanks @T3P3Tony . I'll test your files within the hour.

T3P3Tony

@gtj0 they are very specific to my setup!

gtj0

@T3P3Tony Ha! of course. I meant "I'll adapt your homing methodology to my printer"

gtj0

@T3P3Tony I've adapted your homing files and they do seem to work but they highlight a few issues...
It's a lot of gyrations to go through that we didn't have to go through before and the bit about moving away from the endstops to make sure they're not triggered isn't going to work if you're already at the upper limit of one of the axes. It also makes a homexy.g redundant since homex.g has to homey.g first.

Since I only switched from Cartesian to CoreXY recently, I'm not sure if long standing CoreXY users normally do a move away from the endstops first but it's certainly not documented that way.

Hopefully long standing CoreXY users will chime in.

T3P3Tony

@gtj0 not sure. for reference these hare the homing files for the e3d toolchanger for Duet 2:

https://github.com/e3donline/RepRapFirmware-SD/tree/master/sys

The issue is they use stall detection rather than switches

gtj0

@T3P3Tony Maybe I'll give stall detection a try this weekend.

Nuramori

@T3P3Tony said in RRF3 Homing Issues:

Home X always calls home Y first due to an issue with X movement if the tool pickup head is at Y max on the toolchanger.

aaaaah, I wonder if this is a key part of my issue - the BLV cube uses a Y max approach. I'll modify my homing files later and test your settings (in concept).

dc42

It's normal for stall detection homing to need a small (>=1 full step) movement away from the endstop sometimes before the homing move, to ensure that the motor doesn't register as stalled to start with. But that shouldn't apply to regular endstops such as microswitches. That said, the endstop detection code in RRF 3 is very different from RRF 2, so bugs may have crept in.

gtj0

So now I have XY and Z homing OK (kinda).
Occasionally, either X or Y get reported as being slightly off from expected...

dc42

@gtj0 said in RRF3 Homing Issues:

So now I have XY and Z homing OK (kinda).
Occasionally, either X or Y get reported as being slightly off from expected...

What was expected?

gtj0

@dc42 said in RRF3 Homing Issues:

What was expected?

Sorry. @T3P3Tony's homing macros (above) move the tool to X2 Y2 after homing to keep the tool off the endstops so the final position should be X2.0 Y2.0. Sometime's it's a little more than 2 and sometimes a little less.

gtj0

Just a little update on this... I'm finding that the use of M400 and/or nested macros in the homing cycle casues weird issues where moves will complete only partially and leave axes unhomed and the firmware in a permanent "Busy" state. I'm going to try and create some specific failure scenarios this afternoon.

Also, am I imagining this or didn't the firmware used to run home*.g files if the G28 axes matched? For instance, If I call G28 XY didn't the firmware used to automatically call homexy.g instead of homex.g + homey.g?

T3P3Tony

@gtj0 said in RRF3 Homing Issues:

For instance, If I call G28 XY didn't the firmware used to automatically call homexy.g instead of homex.g + homey.g?

If it did its a feature i never heard of. The only combined homing files I know of are homeall and homedelta. That said @dc42 might have snuck the feature in without me noticing