RRF3 Sensorless Homing issue/bug



  • 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
    

  • administrators

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



  • @dc42 My apologies. Cartesian



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

    1. emergency stop or fresh boot condition
    2. press home x.
    3. x axis moves to the endstop and sets X=0
    4. throws error and remainder of the file is ignored.
    5. press home y
    6. y axis moves to endstop and sets Y=0
    7. No error is thrown and axis move to 125,100 as expected
    8. 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
    

  • administrators

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


  • administrators

    Please re-test this using RRF 3.0beta12.



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


  • administrators

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


  • administrators

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


  • 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



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


  • administrators

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



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


  • administrators

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



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


  • administrators

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



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

  • administrators

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



  • @dc42 said in RRF3 Sensorless Homing issue/bug:

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

    Cool.


Log in to reply