RRF3 Homing Issues

gtj0

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

T3P3Tony

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

Nuramori

yeah, there's still something up. With beta 11, my gantry decided to just ignore the endstop randomly, and snapped the endstop mount as it plowed through it. ugh.

I'm gonna move to an optical endstop and see if it helps. Mechanical switch checks out - not that, and not the wiring. signal trips properly, as in the lights toggle with the switch action.

dc42

@gtj0, I am working through bugs that have been reported in RRF3. Are you still having trouble when endstops are already triggered when you try to home the printer? If so:

Please try the latest firmware build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 and see if it still happens
If it does, please report the type of endstop switch you are using, what type of printer you have (Cartesian, CoreXY etc.), and whether this issue occurs when you home individual axes or only when you homeall. I appreciate that you may have provided some of this information already, but this thread is quite long now.

When using stall detection endstops, it's a known issue that homing will fail if the motor is already flagged as stalled. The remedy is to move each axis a tiny bit away from the endstop before executing the first homing move. One full motor step is enough.

Danal

Running dropbox beta11+1, home (still) fails when axis on switch at time of G28. My X axis is configured to use a physical microswitch, wired NC, and to allow 5mm from switch to 0,0.

M208 X-5:305
M558 P5 C"io3.in" H5 A5 T6000  S0.02

Demonstration of failure:

G28 X
10/29/2019, 10:03:25 AM	G28 X (in green; succeded)
G1 X-5 (also green; this places axis in physical contact with switch)
G28 X
10/29/2019, 10:03:37 AM	Error: G0/G1: insufficient axes homed (in red)
G1 X5
10/29/2019, 10:03:37 AM	G1 X5  (in red)
                        Error: Code has been cancelled

Content of homex.g:

; Home X Axis
G91                     ; Set relative mode
G1 X-330 F6000 H1       ; Big negative move to search for endstop
G1 X4 F600              ; Back off the endstop
G1 X-10 F600 H1         ; Find endstop again slowly
G90                     ; Set absolute mode
G1 X0 F6000

Releases installed:

10/29/2019, 10:01:27 AM	M115 B0
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.0beta11+1 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2019-10-27b1

10/29/2019, 10:01:23 AM	M115 B1
Board EXP3HC firmware 3.0beta1 2019-10-27b4

dc42

@Danal, thanks for that. I'll test it on my bench setup - I don't yet have a luxury of a real printer running Duet 3 due to lack of space, although others in Duet3D do.

gtj0

@dc42 Yes still having problems...

CoreXY
X endstop is actually one of your IR probes (I was testing various types to see if any worked better)
Y endstop is an optical interrupter.
Z endstop is a piezo Orion.

No stall detection.

Individual axes will home ok IF the axis doesn't have to travel far for the first move. I.E. If the X axis is at +10 it will home OK. If it's at +50, the initial move (coarse) will complete but the fine move won't and the axis will be left in an unhomed state. Same for Y and Z. If I add an M400 after the coarse move, it increases the chance that the homing will complete but there's still about a 10% failure rate. If I add an M400 after every move in the macro, it's about 99% successful. However, about 10% of the time (even when homing is successful), either X or Y will be left at some position between -1.0 and +1.0 but not equal to 0.0.

homex.g
homey.g
homez.g

I also have a homexy.g that homes both X and Y together but oddly enough, I don't need to do the M400's. Maybe because it's executed as a generic macro not a special homing file? This got me thinking so I ran my homex.g and homey.g files as macros with M98 and without the M400s and sure enough they worked fine.

homexy.g

As for homeall.g, when it simply runs homexy.g and homez.g with M98, it works fine. If I copy all the raw GCode commands into homeall.g, I need copious M400s.

homeall.g