3.5b4 - Abort while homing does not leave homing context

pfn

I updated my homing scripts to be aware of an endstop/sensorless homing failure by adding logic to detect the position after the second pass homing move if it is out of range like so:

if !move.axes[0].homed
	; raise Z a bit
	G91
	G1 H2 Z5 F2400
	G90

; reset current position to 0
G92 Y0

G91
; Move quickly to Y axis endstop and stop there (first pass)
G1 Y315 F12000 H1

; Go back a few mm
G1 Y-5 F18000

; Move slowly to Y axis endstop once more (second pass)
G1 Y10 F360 H4

if move.axes[1].machinePosition > move.axes[1].max || move.axes[1].machinePosition + 2 < move.axes[1].max
  M84 Y
  abort "Homing Y failed"
  
G92 Y{move.axes[1].max}
G90

Now, if the homing move doesn't operate the endstop successfully, the homing script will abort. The interesting thing is, when the homing script is aborted, if I try to home again, I get this error: Error: G28: G28 may not be used within a homing file

After the error occurs once, I can then proceed to home again. It is as if the previous homing context that is currently running has not exited up a stack level.

However, I am not sure if this problem is a regression in b4 or always been present. I only just added this logic into my homing scripts due to a wiring problem that has manifested in my endstops over the last few days.

In case there is more going on due to multiple levels of stack, I am reproducing the above by running this macro over and over until my endstop triggers incorrectly, at which point the first subsequent G28 Y results in the error described:

G1 Y0 F18000
G28 Y

pfn

Interestingly, if I do this on 2 different inputs, e.g. I run the testing macro on my 12864 display and force the homing to fail (depressing the endstop before the Y endstop actually hits the end), homing is blocked on DWC, i.e. DWC spins and blocks waiting for a result when I send G28 Y.

In order to clear this state, I have to G28 Y from the 12864 display.

pfn

@dc42 ping!

p8blr

@pfn I too would like an update on this. I'm using the 3.5 release candidate and have this same issue. I have my homez.g verify the state of an output and abort if it's not in the correct state, however, it seems to ignore the abort command and continue running.

at the beginning of homez.g:

if state.gpOut[0].pwm != 1 && state.gpOut[1].pwm != 1 && state.gpOut[2].pwm != 1 && state.gpOut[3].pwm != 1
    M291 P"Enable all vacuum zones. Aborting..." S2
    abort

if state.gpOut[0].pwm != 1
    M291 P"Enable vacuum zone 1. Aborting..." S2

if state.gpOut[1].pwm != 1
    M291 P"Enable vacuum zone 2. Aborting..." S2

if state.gpOut[2].pwm != 1
    M291 P"Enable vacuum zone 3. Aborting..." S2

if state.gpOut[3].pwm != 1
    M291 P"Enable vacuum zone 4. Aborting..." S2

if state.gpOut[0].pwm != 1 || state.gpOut[1].pwm != 1 || state.gpOut[2].pwm != 1 || state.gpOut[3].pwm != 1
    abort

Maybe @dc42 has a suggestion?

chrishamm

@p8blr This is planned for v3.6, see https://github.com/Duet3D/RepRapFirmware/issues/765

T3P3 created this issue in Duet3D/RepRapFirmware

3.5b4 - Abort while homing does not leave homing context

open Allow aborting macros Including homing moves - "not quite an emergency, but STOP" #765