Sensorless homing not working on 1LC

[Aurimas]

ok, this time it is 1LC issue
trying to do sensorless homing and cannot get it to work - no matter what I do.
Same settings on Mini 5+ - no issues at all.
I have tried to go down to 10% with current while homing
fast speed, low speed - no chages
changed S to values all the way down to -128 - still nothing.

@dc42 is sensorless homing enabled on 3.6.0B3 and RC1?
No need to ask for config file - other axis works just fine with the same homing file and settings.

[dc42]

@Aurimas yes it's enabled in rc1.

[Aurimas]

@dc42 can't get to work - max sensitivity of -128, 10% power, different speeds
What would you suggest?

[gloomyandy]

@Aurimas I'd suggest that you create a simple test case. A macro that contains all of the settings for the driver that you are trying to get to stall along with the stall detect settings and the actual homing move. Basically something that DC42 (or another developer) can easily run to replicate whatever it is that you are doing.

[Aurimas]

@gloomyandy would you have one ready?

[gloomyandy]

@Aurimas None of the expansion boards that I support/work on have stall detection enabled, so it is not something I've ever had any need for. But I'd say the fastest way to get this checked (and if needed fixed) is to make it easy for others to test.

[dc42]

@Aurimas said in Sensorless homing not working on 1LC:

@dc42 can't get to work - max sensitivity of -128, 10% power, different speeds
What would you suggest?

When you attempt a G1 H1 move on the 1LC, does the motor actually move?

[Aurimas]

@dc42 yes. There is no issue at all. Works fine with mechanical endstop. It simply doesn't detect sensorless stall so the motor keeps rattling when it hits end

[JoA-RHU]

Hi there,

I'm in the same situation...
@Aurimas did you find a solution?

Thanks

[droftarts]

@Aurimas @JoA-RHU

I've been testing this today, and have the same issue with a Mini 5+ and 1LC, on RRF 3.6.0-rc.1+2. I've highlighted this to @dc42. This is my macro, which works when connected to Mini 5+, but doesn't (with same settings) when connected to 1LC:

; extruder filament stall test
; setup

; extruder on Mini 5+
;M569 P0.3 S1 D3 V0   ; set driver to stealthChop, required for stall homing on TMC2209
;M584 E0.3            ; set extruder mapping

; extruder on 1LC
M569 P121.0 S0 D3 V0 ; set driver to stealthChop, required for stall homing on TMC2209
M584 E121.0          ; set extruder mapping

; extruder config
M906 E1000           ; set extruder driver currents
M350 E16 I1          ; configure microstepping with interpolation
M92 E397             ; configure steps per mm
M566 E300            ; set maximum instantaneous speed changes (mm/min)
M203 E3600           ; set maximum speeds (mm/min)
M201 E600            ; set accelerations (mm/s^2)

; filament stall homing

M302 P1              ; allow cold extrude
T0                   ; select tool

M915 E0 H50 S3       ; set stall sensitivity
M913 E30             ; motor current to 30%
M83                  ; relative extrusion
G1 H1 E100 F1200     ; feed up to 100mm until stall

M913 E100            ; restore normal motor current
M302 P0              ; deny cold extrude

Ian

[JoA-RHU]

@droftarts @dc42

As I’ve been thoroughly reading the Trinamic documentation to better understand their technology (StealthChop, SpreadCycle, CoolStep, StallGuard, etc.), I also examined the expansion board firmware and believe I’ve identified the issue.

In the TMC22xx.cpp file, an interrupt is defined for the "diag" pin, but it seems it is disabled by default.

#if HAS_STALL_DETECT
	diagPin = p_diagPin;
	IoPort::SetPinMode(p_diagPin, INPUT_PULLUP, false);
	AttachPinInterrupt(p_diagPin, DiagPinInterruptEntry, InterruptMode::rising, CallbackParameter(p_driverNumber), false);
	// Leave the interrupt disabled until we enable a stall endstop on this driver
#endif

Later, in the SmartDrivers::SetStallEndstopReporting function, it looks like we're missing a call to TmcDriverState::EnableDiagInterrupt, which prevents the interrupt from ever being enabled.

GCodeResult SmartDrivers::SetStallEndstopReporting(uint16_t driverNumber, float speed, const StringRef& reply) noexcept
{
	if (driverNumber < GetNumTmcDrivers())
	{
		const char *_ecv_array _ecv_null const msg = driverStates[driverNumber].CheckStallDetectionEnabled(speed);
		if (msg == nullptr)
		{
			stallEndstopsEnabled.SetBit(driverNumber);
			return GCodeResult::ok;
		}
		reply.printf(msg, CanInterface::GetCanAddress(), driverNumber);
		return GCodeResult::error;
	}
	else
	{
		stallEndstopsEnabled.Clear();
		for (TmcDriverState& ds : driverStates)
		{
			ds.DisableDiagInterrupt();
		}
		driverStallsToNotify = 0;
		return GCodeResult::ok;
	}
}

I'll have a try on Monday and keep you posted.

[droftarts]

@JoA-RHU Thanks, we're looking at this today. I've highlighted your suggestions to @dc42.

Ian

[JoA-RHU]

@droftarts @dc42 By the way, there's another issue related to smart drivers on expansion boards. The parameter C of M569 is not handled (yet?).

[dc42]

@JoA-RHU thanks for your contribution. I already added that missing call this morning, however it's not sufficient to make stall detection reliable. We're still working on it.

[dc42]

@JoA-RHU please try the firmware binary at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0.

[JoA-RHU]

@dc42 Thanks for the the binary. I tested it today, but couldn't setup a proper stall detection.
Either a stall is detected immediately on the start of the first G1 H1 motion (and then never again).
Or it is not detected at all.

Maybe it's worth mentioning that I'm using the 1LC to control a small auxiliary axis. Nema 11 stepper motor with 670mA nominal current, ball screw linear axis with 1mm pitch, max. speed ~15mm/s (900rpm).

Is there a way to report the value of SG_RESULT register while moving the axis?

[dc42]

@JoA-RHU said in Sensorless homing not working on 1LC:

Either a stall is detected immediately on the start of the first G1 H1 motion

Have you tried reducing the M201.1 acceleration for special moves on that axis or extruder? The acceleration at the start of the move may be triggering the stall detection.

[JoA-RHU]

@dc42 I tried reducing the "special moves" acceleration with M201.1.

I finally managed to set up sensorless homing, but it's still not very stable. I believe the issue is more related to the configuration than the threshold value.

Occasionally, a stall is detected at the start of the first homing motion but never again. Restarting the mainboard sometimes resolves the issue, but it tends to reappear after 2-3 reboots.

I ended up with with this homing file (axis is C) :

M400
M574 C1 S3 ; setup sensorless endstop
M915 C R0 S40 ; set sensitivity
M569 P22.0 V11 ; increase TPWMTHRS
M913 C30 ; reduce current to 30%
M400
G4 P500 ; wait 500ms - don't know if usefull
G91
G1 H1 C-75 F120
G1 C0.5 F600
G90
M400
M569 P22.0 V117 ; restore TPWMTHRS
M574 C0 ; remove endstop
M913 C100 ; reset current to 100%
M400

As you can see I'm creating and deleting the endstop every time. I don't know why, but it's the most stable configuration I could find.

[droftarts]

@JoA-RHU @dc42

I also tested this, and found the same problem. While I could get sensorless homing to work on the 1LC, it needed quite different setting than with the same motor connected to the Mini 5+. Like you, it wasn't very stable or repeatable.

Ian

[dc42]

@JoA-RHU In general, when using stall homing you need to account for the possibility that the motor may be reporting a stall already. Do this by commanding a short G1 H2 move before the G1 H1 move. It can either be in the opposite direction to the G1 H1 move (which is usually the best choice when homing an axis) or in the same direction (which may be better when loading filament).

There are additional considerations when more than one axis/extruder is mapped to the same drive. See https://github.com/Duet3D/RepRapFirmware/issues/1098.

dc42 created this issue 24 Mar 2025, 14:56 in Duet3D/RepRapFirmware

open Stall detection issues when a drive is used by both an axis and an extruder #1098