Sensorless homing not working on 1LC
-
-
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
-
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.cppfile, 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::SetStallEndstopReportingfunction, it looks like we're missing a call toTmcDriverState::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 @dc42 By the way, there's another issue related to smart drivers on expansion boards. The parameter
CofM569is not handled (yet?). -
@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.
-
@JoA-RHU please try the firmware binary at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0.
-
@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 firstG1 H1motion (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?
-
@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.
-
@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.
-
-
@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.
