RRF 3.4.0 Sensorless Homing Issues after Power Cycle

flobler

@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

flobler

@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

@dc42 @Phaedrux is anyone have some news on that ? That's kind off a weird issue...

dc42

@krohm-koala you should perform stealthChop tuning in the homing files before executing the homing move.

flobler

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

Del87

@flobler mb because stealthchop is not default mode on 3.4 anymore

Krohm Koala

@del87 but Everything is set to stealthchop in config.g so it should be a problem

flobler

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

gloomyandy

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

flobler

@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

@dc42 @Phaedrux I have not managed to figure out what I am doing wrong yet and the behavior is still consistent across two machines.

Do you have any hints? Is my driver tuning procedure configured wong?

Thank you

P.S.: May I aske why this is categorized under "Beta Firmware"?

oliof

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

flobler

@oliof thank you, I will give that a go and report back!

flobler

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

oliof

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

flobler

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

oliof

@flobler https://github.com/oliof/printerconfigs/blob/main/v-minion/sys/homex.g

dc42

@flobler your homing files are not right for the Duet 3 Mini because you are not executing the required stealthChop tuning move. For example, the first X move you do in homeall.g is this:

G1 H1 X5 F1200

Try this instead:

M17 X
G4 P140
G1 H2 X5 F1200

flobler

@dc42 Thank you! I just tried that but the behavior did not change. X and Y are still stalling immediately when trying to home after a power cycle and home fine after that initial false stall until I power cycle the printer again.

I had a tuning move included in homing-modifications.g (which I removed to test what you suggested).

dc42

@flobler when you try to home after a power cycle, does each of the X and Y axes move 5mm away from the endstop before the premature stall?