RRF3 Sensorless Homing issue/bug

ctilley79

I'm testing RRF3 beta and ran into an issue when using sensorless homing on my Duet 2 WiFi. My home X, Y, and Z files work as expected, but my home all file has the following symptom. As soon as the X axis homes off of X min, the y axis stops as well resulting in an incorrect home location for Y. Conversely, if the Y axis reaches the endstop first, it results in an incorrect position for X. My homeall.g is as follows.

M561			; unload heightmap
M400                    ; make sure everything has stopped before we make changes
G91                     ; relative positioning
M574 X1 Y1 S3           ; set endstops to use stall detection
M913 X30 Y30   		; reduce motor current
G1 X5 Y5 Z2 F6000	; lift Z relative to current position
G1 H1 X-270 Y-220 F6000 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y-5 F8000 H2      ; go back a few mm
M400  			; make sure everything has stopped before we make changes
M913 X100 Y100          ; motor currents back to normal
G1 Z2 F6000 H2		; raise head 2mm to ensure it is above the Z probe trigger height
G90 			; back to absolute mode
G1 X100 Y100 H2  F6000	; put head over the centre of the bed, or wherever you want to probe
G30 			; lower head, stop when probe triggered and set Z to trigger height

dc42

Is this a Cartesian printer, a CoreXY, or something else?

ctilley79

@dc42 My apologies. Cartesian

ctilley79

@dc42 I was able to temporarily get around the problem by homing the X and Y axis individually. Some additional buggy behavior, occasionally I do get an "G28 X G0/G1insufficient axes homed" error in the web interface when using the home_x and home_y files. This happens after a fresh boot or after an emergency stop. The axis stops and home is set, however the remaining part of the file isn't processed. The problem persists until the other axis is also homed. For example....

emergency stop or fresh boot condition
press home x.
x axis moves to the endstop and sets X=0
throws error and remainder of the file is ignored.
press home y
y axis moves to endstop and sets Y=0
No error is thrown and axis move to 125,100 as expected
home x now works

; homex.g
; called to home the X axis
M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X40           	; reduce motor current to 50% to prevent belts slipping
G91			; use relative positioning
G1 H2 X15 Z5		; Move Z and Y up for a running start
G1 H1 X-270 F6000	; move all carriages up 700mm, stopping at the endstops  
G90			; back to absolute positioning
M400                    ; make sure everything has stopped before we reset the motor currents
M913 X100		; motor currents back to normal
G1 X125 Y100 F6000	; centre the head and set a reasonable feed rate

dc42

Thanks for your report - it's on my list to investigate.

dc42

Please re-test this using RRF 3.0beta12.

ctilley79

Still broken. Whichever axis hits the stop first, home still gets set for both X and Y at that point.

dc42

@ctilley79 said in RRF3 Sensorless Homing issue/bug:

Still broken. Whichever axis hits the stop first, home still gets set for both X and Y at that point.

Thanks, I think I have found the reason for this behaviour, which i will fix in the next build.

dc42

There is a new build in https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 that may fix the problem. Try it if you wish. Caution, this isn't an official release so it has had very limited testing.

gtj0

@dc42 said in RRF3 Sensorless Homing issue/bug:

There is a new build in https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 that may fix the problem. Try it if you wish. Caution, this isn't an official release so it has had very limited testing.

@dc42, that firmware build results in an RepRapFirmware got a bad header checksum error when installed and flashed via M997 and the following error when flashed by bossac:

Erase flash

Done in 0.001 seconds
Write 473680 bytes to flash (926 pages)
[==============================] 100% (926/926 pages)
Done in 6.245 seconds
Verify 473680 bytes of flash
[==============================] 100% (926/926 pages)
Verify failed
Page errors: 926
Byte errors: 469070

gtj0

Oh scratch that. I left the reset jumper in place.

However, the build still doesn't boot probably because of...
https://github.com/dc42/RepRapFirmware/issues/337

gtjoseph created this issue in dc42/RepRapFirmware

closed Enabling MCU might have broken Duet3 #337

ctilley79

@dc42 Sounds good. I'm in no hurry. Homing each axis individually works fine for now.

dc42

@gtj0 , which version of Duet 3 do you have? I tested on v0.6 but not on 0.5.

gtj0

@dc42 said in RRF3 Sensorless Homing issue/bug:

@gtj0 , which version of Duet 3 do you have? I tested on v0.6 but not on 0.5.

v0.6. I tested the binary in the zip file you linked as well as building from v3-dev source up to commit "Removed SD-image folder". When the binary loads the status LED starts flickering very dimly.

dc42

@gtj0 said in RRF3 Sensorless Homing issue/bug:

@dc42 said in RRF3 Sensorless Homing issue/bug:

@gtj0 , which version of Duet 3 do you have? I tested on v0.6 but not on 0.5.

v0.6. I tested the binary in the zip file you linked as well as building from v3-dev source up to commit "Removed SD-image folder". When the binary loads the status LED starts flickering very dimly.

Odd, that binary is working for me and for deckingman. Did you pick up all the changes, to CoreNG, FreeRTOS, CANlib and RRFlibraries? Did you do a complete clean before the build? The compiler options have changed, so that's necessary.

After you load a version that works, with luck the software reset data in M122 will help pinpoint the crash.

PS - one other question: what does the LED do if you boot up without the Pi ribbon cable connected?

gtj0

@dc42 Well, this is interesting. Using the binary in your zip file, disconnecting the ribbon cable immediately causes the status LED to flash once per second as normal. Plugging the cable back in again and it goes back to dimly flashing quickly. Rebooting the SBC causes the Duet to back to normal UNTIL the DuetControlServer starts, then it's back to flashing dimly and quickly. Sure enough stopping the DCS and it's back to normal.

dc42

@gtj0 said in RRF3 Sensorless Homing issue/bug:

@dc42 Well, this is interesting. Using the binary in your zip file, disconnecting the ribbon cable immediately causes the status LED to flash once per second as normal. Plugging the cable back in again and it goes back to dimly flashing quickly. Rebooting the SBC causes the Duet to back to normal UNTIL the DuetControlServer starts, then it's back to flashing dimly and quickly. Sure enough stopping the DCS and it's back to normal.

Thanks, looks like there is a memory access within the SBC interface module that upsets the MPU. Can you get an M122 listing of the software reset data, for example via USB?

gtj0

@dc42

Last reset 00:00:12 ago, cause: software

Last software reset time unknown, reason: Memory protection fault, spinning module 
LinuxInterface, available RAM 102672 bytes (slot 2)
Software reset code 0x4170 HFSR 0x00000000 CFSR 0x00000082 ICSR 0x0440f804 BFAR 0x00000000 SP 0x20415f7c Task 0x4e49414d
Stack: 00453aad 0045ff80 01000000 20422334 00000000 00000101 00436243 00000000 20415fa4 00000101 00000000 00000001 20420dfc 00000001 00000000 00000000 004541bd 40058000 00000000 04042001 40078000 00000079 20423d00
Error status: 0 Free file entries: 10

dc42

Thanks, I'll look up the faulting address (45ff80) and see what's causing it.

gtj0

@dc42 said in RRF3 Sensorless Homing issue/bug:

Thanks, I'll look up the faulting address (45ff80) and see what's causing it.

Cool.