Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Sensorless homing not working on 1LC

    Scheduled Pinned Locked Moved
    General Discussion
    5
    20
    382
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JoA-RHUundefined
      JoA-RHU
      last edited by 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.

      droftartsundefined dc42undefined 2 Replies Last reply Reply Quote 0
      • droftartsundefined
        droftarts administrators @JoA-RHU
        last edited by

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

        Ian

        Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

        1 Reply Last reply Reply Quote 0
        • JoA-RHUundefined
          JoA-RHU
          last edited by

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

          dc42undefined 1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators @JoA-RHU
            last edited by

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

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            1 Reply Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators @JoA-RHU
              last edited by

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

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              JoA-RHUundefined 1 Reply Last reply Reply Quote 0
              • JoA-RHUundefined
                JoA-RHU @dc42
                last edited by 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?

                dc42undefined 1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators @JoA-RHU
                  last edited by

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

                  Duet WiFi hardware designer and firmware engineer
                  Please do not ask me for Duet support via PM or email, use the forum
                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                  JoA-RHUundefined 1 Reply Last reply Reply Quote 0
                  • JoA-RHUundefined
                    JoA-RHU @dc42
                    last edited by

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

                    droftartsundefined dc42undefined 2 Replies Last reply Reply Quote 0
                    • droftartsundefined
                      droftarts administrators @JoA-RHU
                      last edited by

                      @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

                      Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                      1 Reply Last reply Reply Quote 0
                      • dc42undefined
                        dc42 administrators @JoA-RHU
                        last edited by

                        @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 in Duet3D/RepRapFirmware

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

                        Duet WiFi hardware designer and firmware engineer
                        Please do not ask me for Duet support via PM or email, use the forum
                        http://www.escher3d.com, https://miscsolutions.wordpress.com

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA