Solved Assistance with odd issue while homing Z
-
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?
-
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..
-
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.
-
@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.
-
@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!
-
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