Assistance with odd issue while homing Z



  • Preface: our printer works a little different than most as than gantry moves in XY&Z and the bed is stationary.

    We are using Duet3/RPi combos and are currently running 3.2b1, but this was happening before on 3.1.1.

    Our routine to home Z (posted below) works by sensorlessly homing Z upwards, then brings it back down to allow the BLTouch to find absolute 0. It works great.

    The issue is that, randomly - but never after reboot, the move to lift the gantry upwards immediately stalls. It's always the rapid move upwards. And again, it never happens after rebooting and starting fresh.

    My request is for ideas on what could be causing this? It usually happens after completing a print and starting another. Nowhere else are currents percentages modified, so I am at a loss as to what is happening..

    Is there any safeguards I could add to homez.g to reset this? Thanks!

    ; == home the Z axis ================================================
    
    M400					; wait until idle
    
    if move.axes[0].homed == false
      M98 P"homex.g"
    if move.axes[1].homed == false
      M98 P"homey.g"
    
    G1 X130 Y130 F24000			; aligns BLTouch in center of build plate
    
    M280 P0 S160				; resets BL Touch
    
    M913 Z85				; adjusts motor current
    M915 P0:5 S5 R0 F0			; set stall detection for motors 0 & 5
    
    G91					; use relative positioning
    
    G1 Z330 F2400 H1			; move Z up and stop at end
    M400					; wait until idle
    
    G1 Z-2 F1000				; move Z downward for second pass
    M400					; wait until idle
    
    M913 Z80				; adjusts motor current
    M915 P0:5 S0 R0 F0			; set stall detection for motors 0 & 1
    
    G1 Z5 F200 H1				; move Z up and stop at end
    M400					; wait until idle
    	
    G90					; back to absolute positioning
    M913 Z100				; motor currents back to 100%
    
    M291 S3 R"Max Z?" P"Please confirm gantry is at max Z"
    
    G92 Z315				; sets Z to 315mm
    
    G1 Z3 F2400				; moves Z downward to probe bed
    M400                   		 	; wait until idle
    
    G30					; sets z-height relative to print bed
    
    M561					; clear any bed transforms
    G30 P0 X20 Y150 Z-99999			; probe midway between front and rear belt on left side
    G30 P1 X280 Y150 Z-99999 S2		; probe midway between front and rear belt on right side
    
    G1 X0 Y0 Z10 F24000			; park the extruder
    


  • do you have stealthchop2 enabled? this gets calibrated after the first move. that could be an issue.



  • @Veti said in Assistance with odd issue while homing Z:

    stealthchop2

    No. I'm using the default.. spreadCycle.

    ;== Drives ===========================
    M569 P0.0 S0					; Defines physical drive 0.0 to move backwards
    M569 P0.5 S1					; Defines physical drive 0.1 to move forwards
    M569 P0.2 S1					; Defines physical drive 0.2 to move forwards
    M569 P0.3 S1					; Defines physical drive 0.3 to move forwards
    M569 P20.0 S0					; Defines physical drive 20.0 to move forwards
    
    M584 Z0.0:0.5 X0.2 Y0.3 E20.0			; Binds Z to 0.0 & 0.5, X to 0.2, Y to 0.3, and E to 20.0
    


  • Do you have them set to reduce the current when idle (via the I parameter to M906?). If you do (or even if you don't), you may want to "wake them up" by performing a very short move (like 0.01mm) without stall detection enabled before your actual rapid move. This can also help to "unstick" a gantry if using a threaded rod drive.



  • I do have them idling down.. that could be related. What I tried before posting this was raising the gantry 1mm before lower the current but it still happened.. but now I'm thinking I should try again with a G4 wait to give it time to ramp up.



  • OK.. I believe this is related to the steppers idling down and needing time to wake up. I added the following to my homez.g. While it still exhibited the same behavior, I heard the motors energize right after and homing Z a second time worked. Maybe I need to pause longer..

    edit - increasing the pause to 2000ms appears to have worked, but it's going to take some more testing. I'm probably going to reduce it to 1000ms and try again.

    G92 Z0
    G1 Z.2 F1000
    G4 P333
    

    I have a 30 second idle set in M84 (M84 S30). I cannot reproduce after 30 seconds.. it must sit for longer than this.

    Is there some other state the steppers can go into after a longer period of inactivity?


  • Moderator

    Reducing acceleration/jerk temporarily for the homing move can help reduce false stalls.



  • ok, what I tried earlier did not fix the issue. It's currently in what I've dubbed "limp mode" on the z-axis. I know rebooting will fix it but I'm still trying to understand what has caused it.

    I guess I could try messing with acceleration and jerk, but why does it work just fine after reboot? that's what baffles me as no changes to acceleration or jerk have occurred since it was last rebooted. The only significant thing is that it's set idle for 30+ minutes..

    Edit - and just like that, I was able to get it working, but I'm going to have to do more testing on what fixed it as I changed multiple things at once. I'm starting to suspect I need to put a G4 wait in between the G92 Z0 and the G1 Z.2 F1000 from the snippet above..


  • Moderator

    Well a reboot would execute config.g and reset any changed values. Do you have motor currents or anything altered during operation that don't get reset?

    If you send M98 P"config.g" instead of rebooting does that also work?



  • I'm going to wait an hour for it to happen again and do some more testing and will report back. I appreciate the help on this as I know it's fixable.

    What was most interesting is that I could use DWC and the PanelDue to move the Z-axis without issue both before and after running homez.g, but homez.g would fail the same way each time.


  • Moderator

    @oozeBot said in Assistance with odd issue while homing Z:

                                                                                                                                                                             M913 Z85				; adjusts motor current
    

    Don't know if it will matter in this case but it's recommended to use M400 immediately before M913.



  • @Phaedrux that's a good call out.. I'll update my script. Thanks!



  • Updated script below. This time I did a fresh reboot after upgrading to 3.2b2 and just let the printer sit idle for 1 hour.

    Check out line 14. If this line is set to 2mm, the z-lift on line 24 fails - every time.

    Once set to 5mm, it succeeded. This feels wrong. I really don't like having to lift the gantry +1mm to work around this and would really appreciate feedback on what could be causing it.

    Again, if I reboot, the script succeeds with no issues without adding lines 12 - 15. It also succeeds if I wait for the 30s idle timeout I have set. It is only after the printer sits idle for ~1 hour.. what could be causing this?

    ; == home the Z axis ================================================
    M400                    ; wait until idle
    
    if move.axes[0].homed == false
      M98 P"homex.g"
    if move.axes[1].homed == false
      M98 P"homey.g"
    
    G1 X130 Y130 F24000	; aligns BLTouch in center of build plate
    M400                    ; wait until idle
    
    M913 Z100
    G92 Z0
    G1 Z5 F1000
    M400                    ; wait until idle
    
    M280 P0 S160		; resets BL Touch
    
    M913 Z85		; adjusts motor current to 85%
    M915 P0:5 S5 R0 F0	; set stall detection for motors 0 & 5
    
    G91			; use relative positioning
    
    G1 Z330 F2400 H1	; move Z up and stop at end
    M400			; wait until idle
    
    G1 Z-2 F1000		; move Z downward for second pass
    M400			; wait until idle
    
    M913 Z80		; adjusts motor current to 85%
    M915 P0:5 S0 R0 F0	; set stall detection for motors 0 & 1
    
    G1 Z5 F200 H1		; move Z up and stop at end
    M400			; wait until idle
    	
    G90			; back to absolute positioning
    M913 Z100		; motor currents back to 100%
    
    M291 S3 R"Max Z?" P"Please confirm gantry is at max Z"
    
    G92 Z315		; sets Z to 315mm
    
    G1 Z3 F2400		; moves Z downward to probe bed
    M400                    ; wait until idle
    
    G30			; sets z-height relative to print bed
    
    M561							; clear any bed transforms
    G30 P0 X20 Y150 Z-99999		; probe midway between front and rear belt on left side
    G30 P1 X280 Y150 Z-99999 S2	; probe midway between front and rear belt on right side
    
    G1 X0 Y0 Z10 F24000		; park the extruder
    M400                    	; wait until idle
    
    


  • I've done further testing tonight and it might be about length of time vs amount of travel, however I still haven't pinpointed the issue. All I know for sure is that it acts different after sitting idle for ~1 hour than after a fresh reboot. Like I said, no commands were run on it after rebooting - I just waited an hour.

    This seems fairly easy to reproduce. I can write another macro tomorrow to isolate the behavior and post it after it's tested.

    Also, in the macro I posted, I have the motor current set high to 85% current - that is completely unnecessary. I had set them this high early on thinking that was the issue. After a fresh reboot, the routine works fine with 50% current..



  • What happens if you leave the machine idle for one hour (or even turn it off) and then reboot (without making any attempt to home/move things before the reboot), does it still home correctly then? If it does not home correctly then it may be some sort of mechanical binding being caused by being stationary in the same location for a period of time (or perhaps the holding current is not enough).

    What happens if you wait an hour and then execute config.g via M98 and then home? If home works in this case then you should be able to identify what commands in the config.g are enabling the movement by some sort of binary chop of the config.g content.


  • administrators

    @oozeBot said in Assistance with odd issue while homing Z:

    The issue is that, randomly - but never after reboot, the move to lift the gantry upwards immediately stalls. It's always the rapid move upwards. And again, it never happens after rebooting and starting fresh.
    My request is for ideas on what could be causing this? It usually happens after completing a print and starting another. Nowhere else are currents percentages modified, so I am at a loss as to what is happening..

    Some ideas:

    • Stall detection becomes more sensitive when the motor is hot. Perhaps the higher temperature at the end of a print is causing the stall detection to trigger prematurely? Are you able to increase the stall detection threshold by one in M915?
    • Are you using PrusaSlicer? If so then it may have messed with your maximum acceleration settings.
    • Try reducing acceleration for that rapid homing move.
    • Try backing off slightly after the homing move, then repeat the homing move. I do this on my tool changer, because very occasionally it stalls prematurely.


  • @dc42 thanks for the hints. They did help.. and it appears this is a sensitivity issue as I believe I've been able to work around it. However, I still don't get why it never happens after full reboot. I don't believe it is a heat issue as the steppers wouldn't have had time to cool off much in the few seconds it takes to reboot, but I did check and they were idling at room temp prior to reboot.



  • @oozeBot @gloomyandy once said something about that TMC drivers are "learning". Could be that he have more insight of it!



  • @dc42

    I finally understand this issue and have a workaround. I can now recreate this at will.. it's a timing issue between lowering motor current and the G1 command! By adding a G4 P100, the homing routine works every time.

    I'm OK with this workaround, but felt as if I should raise awareness as this does feel like a defect and certainly isn't documented anywhere.

    Thanks

    M913 Z75					; adjusts motor current
    M915 P0:2 S5 R0 F0				; set stall detection for motors 0 & 2
    G91						; use relative positioning
    G4 P100
    G1 Z330 F2000 H1				; move Z up and stop at end
    

Log in to reply