Sensorless homing not working on 1LC

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.