Solved RRF 3.4.0 Sensorless Homing Issues after Power Cycle
-
@phaedrux he has D3 on each M569 line so can't be that
-
-
@flobler please provide the contents of homing-modifications-reset.g too.
-
@dc42 sure, I forgot about that one.
I also tried to have it all in one file instead of splitting it up. That did not change the behavior.
homing-modifications-reset.g
;----------------------------------------------------------------------- ; homing-modifications-reset.g ; ; Description: ; - system file ; - resets all homing modifications applied in homing_modifications.g ; - used in all homing system files ;----------------------------------------------------------------------- M913 X100 Y100 ; reset X and Y motor current to 100% M569 P0.3 V2000 ; restore default V parameter for X M569 P0.2 V2000 ; restore default V parameter for Y G90 ; absolute positioning
-
-
@dc42 did you have a chance to look into this?
Please feel free to let me know if there is something I can do to help troubleshoot.
-
-
@krohm-koala you should perform stealthChop tuning in the homing files before executing the homing move.
-
@dc42 @Phaedrux to my understanding I am performing the stealthchop tuning in the homing-modifications.g file.
The main issue though is that these files have worked with both my printers for RRF 3.3 but do not work in RRF 3.4.0.
This indicates to me that something has been changed in RRF 3.4.0, preventing us from homing directly after a power cycle.
Am I doing something wrong? If so, why does it work without problem in RRF 3.3?
Thanks for your time!
-
@flobler mb because stealthchop is not default mode on 3.4 anymore
-
@del87 but Everything is set to stealthchop in config.g so it should be a problem
-
@del87 thamks for chiming in but that is accounted for in config.g and I am certain the drivers are set to operate in stealthChop mode when trying to home. Otherwise hpming would not work at all and not just after a power cycle of the printer.
-
@flobler The tuning moves you are using are very small. I wonder if perhaps using a longer move would help? You might also want to add a delay/m400 after the 2nd move as well to see if that makes any difference?
I agree that it is odd that 3.3 works but 3.4 does not, but perhaps your settings were right on the edge and starting in spreadcycle mode then switching to stealthchop mode (which is in effect what now happens in 3.4), results in slightly different "learned" values after tuning? I suppose you could try switching back to 3.3 and capturing the various register contents just before your homing moves and compare those with 3.4.
-
@gloomyandy Thanks for the input! I tried to make the move longer and also to add the second M400 which both did not change the behavior.
What I also tried is to play with the sensitivity for stall detection as I thought maybe something changed here and the drivers are just being configured too sensitive. I used S3 for both axes on RRF 3.3. With RRF 3.4.0 I went all the way up to the least sensitive value (63) which also did not help. The motors still stall immediately when trying to home after a power-cycle.
So to me there is two things than could be going wrong:
a) I am doing something wrong with the tuning move (but I am not sure what and the docs are not very clear here); then I am still a bit confused why it did not happen in RRF 3.3
b) Something changed from RRF 3.3 to 3.4.0 that breaks the stealthChop tuning procedure
If any of my other settings were wrong (i.e. speed, current, acceleration or jerk) then I don't think the motors would home properly after this initial false stall after a power-cycle.
-
-
@flobler I had issues with sensorless homing after updating to 3.4 until I did M569 Pxx D3 at the beginning of the homing file and switched back to normal hybrid mode doing M569 Pxxx D2 at the end. Maybe that helps. Also the documentation recommends homing moves to be above 40mm/sec so I moved to 40mm/sec just so. With the reduced motor power it is just a light tap and the axis is homed.
-
@oliof thank you, I will give that a go and report back!
-
@oliof this did not help in my case. I think in your case you utilized that the drivers were defaulting to stealthChop before going to RRF 3.4.0 and therefore you needed to give them instructions to use stealthChop2 after the upgrade (as with RRF 3.4.0 the default now is spreadCycle).
My problem is not really that homing is not working generally. Homing works totally fine and smooth just not right after I power-cycle my printer when trying to home for the first time.
Thank you for the suggestion though!
-
@flobler well, without my change homing usually did not work at all, including right after turning on the printer. So yours is a bit of a weird one.
-
@oliof yes, that makes sense. I assume before you upgraded to RRF 3.4.0 you did not specifically configure your drivers as D3 (because they did that by default). Now they default to D2, hence you need to tell them specifically to operate in stealthChop2 before homing (via D3).
If you just configure your drivers as D3 now in config.g you should also be able to home just fine without switching between D2 and D3.
May I ask how your homing files look like? I'd like to see if you are doing something different to tune your drivers. Thank you!
-