Sensorless homing not working on 1LC
-
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 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
C
ofM569
is 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 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?
-
@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.