Marlin: TMC2130 SENSORLESS_HOMING only once after power reset

[maniacgit]

Bug Report

• Description: I've enabled SENSORLESS_HOMING to my TMC2130 on X and Y. The first time after a power reset it works as intended. But if I do a new homing the endstops are triggered immediately. A M119 afterwards always reports them as open.
  Reseting by turning off and on again and it works again for the first homing. A soft reset doesn't help.
• Expected behaviour: Multiple G28 should work
• Actual behaviour: Only the first G28 after a power reset works.

EEPROM was reseted after flashing Marlin with this setting enabled.

I've just made a test with M122. It seems after power reset M122 always reports stallguard false for all axis, after the first home it always reports true. I think clearing this register before each home should fix this bug. But I didn't found out how after looking into the tmc library so far.

[teemuatlut]

stallGaurd is read from the DRV_STATUS register which is read only.
Another way could be to toggle the EN pins on and off which could solve this.

[maniacgit]

Switching off the motors on the LCD an do a new homing doesn't help.

According to the datasheet at least one full step is necessary to clean the flag in DRV_STATUS. Since I'm using auto bed leveling this is done by z safe home, but the flag isn't cleared.

In the meantime I made some tests on my X axis. With X_HOMING_SENSITIVITY=25 the flag is cleared and the homing starts, but it detects the collision with the frame to late with this high sensitivity value.

After a power reset X_HOMING_SENSITIVITY=8 works the first time, so in my opinion it should also work for futher homings without power reset.

[maniacgit]

It seems I've found the cause. I'd disabled STEALTHCHOP and in Marlin_main.cpp in the function void tmc_sensorless_homing(TMC &st, bool enable=true) there is an #ifdef for STEALTHCHOP which also sets the coolstep_min_speed.

When I change it like this it works:

void tmc_sensorless_homing(TMC &st, bool enable=true) {
      if (enable) {
        st.coolstep_min_speed(1024UL * 1024UL - 1UL);
    #if ENABLED(STEALTHCHOP)
        st.stealthChop(0);
    #endif
      }
      else {
        st.coolstep_min_speed(0);
    #if ENABLED(STEALTHCHOP)
        st.stealthChop(1);
    #endif
      }
    st.diag1_stall(enable ? 1 : 0);
  }

[ss89]

i can confirm this behaviour in Marlin 1.1.8.
Enabling Stealthchop mode fixes the problem for me.
I also made the threshold for switching to spreadcycle very low, so that i will always be in spreadcycle mode anyway.

[stephenwilley]

+1 - Enabled stealthchop which fixed things for me.

Edit: Went with your code change since I'm using a TMC2130 for a direct drive extruder and stealthchop doesn't cut it.

[marcio-ao]

I encountered this problem as well. I toggle stealth mode on and off in order to reset the stallguard flag. Could not find a better way to do it! This is what my "tmc2130_sensorless_homing" looks like (apologies for all the macros).

    #define LULZBOT_ENABLE_COOLSTEP_WITH_STALLGUARD(st) \
        /* Disable steathchop */ \
        st.stealthChop(0); \
        /* Enable coolstep for all velocities */ \
        st.coolstep_min_speed(1024UL * 1024UL - 1UL); \
        st.sg_min(1); \
        st.sg_max(3);

    #define LULZBOT_ENABLE_STEALTHCHOP(st) \
        /* Enable steathchop */ \
        st.stealthChop(1); \
        /* Disable coolstep */ \
        st.coolstep_min_speed(0); \
        st.sg_min(0); \
        st.sg_max(0);

  void tmc2130_sensorless_homing(TMC2130Stepper &st, bool enable=true) {
    #if defined(LULZBOT_SENSORLESS_HOMING_TOGGLE)
      if (enable) { \
            /* Sometimes the X axis refuses to move at the start of G28, */ \
            /* because the stallguard is triggered. Toggling in and out */ \
            /* of STEALHCHOP mode seems to resolve this. */ \
            LULZBOT_ENABLE_STEALTHCHOP(st) \
            LULZBOT_ENABLE_COOLSTEP_WITH_STALLGUARD(st) \
        } else { \
            LULZBOT_DEFAULT_OPERATING_MODE_XY(st) \
        }
    #elif ENABLED(STEALTHCHOP)
      if (enable) {
        st.coolstep_min_speed(1024UL * 1024UL - 1UL);
        st.stealthChop(0);
      }
      else {
        st.coolstep_min_speed(0);
        st.stealthChop(1);
      }
    #endif
    st.diag1_stall(enable ? 1 : 0);
  }

[thinkyhead]

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see if we fixed this issue. If the problem has been solved then we can close it. If you still see the bad behavior we should investigate further.

[BenBlv]

Same problem in here.

• on stealth mode G28 works as expected without any issues.
• on spreadCycle mode G28 doing it all wrong.

with spreadCycle On after a power cycle:

• X-axis homing correctly
• Y-axis going to the opposite direction
• Z-axis homing correctly

After the first G28, another G28 will result:

• X-axis doesn't move to 0 position (hot homing) but moving to the opposite direction until it hits the end of axis/motor stuttering/ thinks it got to the center (depends where it is)
• Y-axis sometimes moving back and sometimes forward (depends with the position). its doesn't make the homing motion.
• Z-homing correctly.

Motherboard: Gen-L 1.0, tmc2130
v1.1.8 bug fix (today) 4/3 + updated 2130 libraries.
SPI configured and communicates / correct address.
Z safe homing enabled
sensorless homing enabled
BLtouch enabled
Debug tmc enabled

[ghost]

Hi, I also have the same problem on the latest 1.1.x Bugfix.

In stealchchop the printer performed as expected, but when I switch to spredcycle (comment // enable_stealthchop) sensorless homing doesn't work as espected. Instead of going to the end of the axis, it stops in the middle, the crashed into the opposite side

[thinkyhead]

Please start a new issue entitled "TMC2130 SpreadCycle breaks sensorless homing" or similar.

[olafherzig]

+1

Changing 'Marlin_main.cpp.tmc_sensorless_homing' to the following code helped;

void tmc_sensorless_homing(TMC &st, bool enable=true) {
    st.coolstep_min_speed(enable ? 1024UL * 1024UL - 1UL : 0);

    #if ENABLED(STEALTHCHOP)
      st.stealthChop(enable ? 0 : 1);
    #endif

    st.diag1_stall(enable ? 1 : 0);
  }

[marcio-ao]

@olafherzig : Yes, the TMC chip does seem to have a problem with the stallguard flag staying set. It seems like they should have added an option to clear it programmatically. Going in and out of stealth chop is the only way I have found to clear it.

[thinkyhead]

Interesting. What is the added effect of always setting the coolstep_min_speed instead of only when STEALTHCHOP is enabled, as it is currently?

#if ENABLED(STEALTHCHOP)
  st.coolstep_min_speed(enable ? 1024UL * 1024UL - 1UL : 0);
  st.stealthChop(!enable);
#endif
st.diag1_stall(enable ? 1 : 0);

[JimStar]

From 2130 lib docs:

In current code, if stealthChop is disabled, you are only calling coolstep_min_speed() once: during initialization. Thus the first time the homing works always.
But then, after every homing is done, you are _disabling_ the "diag1 active on motor stall", which means you are going to _enable it again_ before homing next time. Which according to docs requires coolstep_min_speed to be set before "diag1 active on motor stall" is enabled _again_.

But the caveat here is, that just setting the same value again by coolstep_min_speed before diag1_stall(1) will not work (I've tried:). You need to reset the coolstep_min_speed to zero before disabling diag1 stall, and set it again to max before enabling diag1 stall. So, because of that the code mentioned by olafherzig or maniacgit works perfectly. The only additional thing to that, IMHO you can remove the redundant coolstep_min_speed() call from tmc2130_init(), because it is not needed anymore (it is anyway _always_ called in tmc_sensorless_homing() before _each_ homing)...

E.g. I've done it in my current 1.1.8 (besides fixing the tmc_sensorless_homing()):

[teemuatlut]

Now that I have a signal analyzer I could finally take a look at what's actually going on when homing with stallGuard.

This is not the signal pattern I would expect and I'll need to ask Trinamic what's going on and if we really have to keep toggling the speed threshold on every homing procedure.

[thinkyhead]

@JimStar — Would the same workaround apply to the current bugfix branches? (Some of the trinamic-oriented code has changed a bit.)

[JimStar]

@thinkyhead
I don't see why not - the code is changed a bit, but the logic is still the same both in bugfix-1.1.x and in bugfix-2.0.x: there is still coolstep_min_speed() called once inside tmc2130_init() (which can be safely removed), and there is still tmc_sensorless_homing() called before and after homing (just the method itself is moved to other place and is not a template anymore - this is just a technical change that definitely doesn't affect the logic)... So, IMHO: must work the same as for 1.1.8.

After I've done those two little changes in 1.1.8 - it never fails homing, it works just perfectly. But without these changes - I got my hot nozzle diving deep into the printed model several times, when I pressed "Auto home" after printing had been finished...
Yes it looks kinda weird that coolstep_min_speed() must be called each time before each diag1_stall() call (might be some bug in 2130) - but at least it works with no fails of homing in 100% of times...

[thinkyhead]

Thanks for the feedback! I'll put together a patch tonight for both bugfix branches.

[thinkyhead]

I've applied the suggested patch. This should also help with sensorless probing once we go forward with that.

[JimStar]

Amazing, thank you, @thinkyhead!

[jarnoburger]

Is this fixed in the latest bugfix 2.0 ?
Because i have the same problem.

[thinkyhead]

Should be.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.