[BUG] Z Stealthchop is destroying baby steps

[emaayan]

Bug Description

when StealthChop for z is enabled trying to do babystepping doesn't work, initially the motor will move just a little then it will stop moving completely and even after the build it won't move at all unless reset

My Configurations

this is marlin build 2.0.x from 18.01.2020

Marlin.zip

Steps to Reproduce

1. enable z stealthchop and babystepping
2. start a print , during pring adjust the knob on the z-offset

Expected behavior: z axis moving according the knob

Actual behavior: z axis stops moving after a few turns and is completely disabled afterwords

Additional Information

hardware is tmc 2208 skr 1.4

[thinkyhead]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[emaayan]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

this w as tested on a firmware from the 18th..

[emaayan]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

this w as tested on a firmware from the 18th..

i've updated the bug when i said 18 i mean from the 18th this month as in marlin 2.0.x

[thinkyhead]

This issue is confirmed. For now the solution is to lower your babystep multiplier setting and re-flash. Try dividing it in half as a starting-point.

[sjasonsmith]

I have been unable to reproduce this. I tried with my original SKR 1.3 configuration, then with several modifications to get closer to the posted configs. I even swapped out my 2208 for the specific module I was using to test shutdowns with linear advance.

During my tests I had visible Z activity due to bed leveling, and also tested in vase mode to allow testing during continuous Z movement.

I'm out of ideas to get it to happen on my machine. My goal was to reproduce the issue, the do a mixed-signal capture of the motor outputs and the step pulses at the same time. My hypothesis is that prior to shutdown, we will see two step pulses unreasonably close together just before the motors turn off.

[sjasonsmith]

Can somebody experiencing this issue post an STL and sliced gcode that you can reproduce it with? Maybe there is capability used in the file (Z-hop maybe?) that behaves poorly along with babystepping.

[emaayan]

Can somebody experiencing this issue post an STL and sliced gcode that you can reproduce it with? Maybe there is capability used in the file (Z-hop maybe?) that behaves poorly along with babystepping.

perhaps it's an issue with 1.4? i don't think it's related to a specific g-code i have several of them

[InsanityAutomation]

Mine hasn't made it here from China yet unfortunately....

[sjasonsmith]

I also have a 1.4 on the way, I doubt that is the issue. The 1.3 and 1.4 just aren't that different. It has also been seen on the TH3D EZBoard.

@emaayan, can you confirm that your 1.4 is the non-turbo version? I know that is what your config says, but perhaps things could misbehave if your board has an LPC1769 (turbo) and you build for LPC1768 (non-turbo).

[sjasonsmith]

i don't think it's related to a specific g-code i have several of them

Your slicer is undoubtedly configured differently than mine, so having a file known to cause issues on your printer might help reproduce it on mine.

[emaayan]

i have pure g-code that also causes this happen, also i have skr 1.4 non-turbo.

On Wed, Jan 22, 2020 at 10:44 AM Jason Smith notifications@github.com wrote:

i don't think it's related to a specific g-code i have several of them

Your slicer is undoubtedly configured differently than mine, so having a file known to cause issues on your printer might help reproduce it on mine.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/16617?email_source=notifications&email_token=ADGP5MARFQTPU3WKBHHPXJDQ7ABQBA5CNFSM4KI4O632YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSWP4Q#issuecomment-577071090, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGP5MATHHN2NS62MTS7PWDQ7ABQBANCNFSM4KI4O63Q .

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?

[thinkyhead]

i have pure g-code that also causes this happen…

@emaayan — If the issue is still occurring, that G-code would be good to check out. Did you ever try reducing the babystep multiplier on your machine, and what value made it work? And, what is your Z steps-per-mm value?

[houseofbugs]

Dropping steps/mm from 800 to 400 (by halving the driver step rate from 1/16 to 1/8) does not show the issue. That is what we did for 800steps/mm machines with the TMC drivers. Have not had an issue since. So there is something going on (maybe driver timings being too quick) when the steps/mm are higher than 400 steps/mm.

You can still run interpolated mode on the TMC driver and there is nothing of value lost running at 1/8 vs 1/16 until the cause of the drivers shutting down when steps on Z are higher than 400steps/mm.

[rado79]

maybe similar experience today - in my start script i do a prime-nozzle-line, i normaly do babystepping while this line is printing,

G1 X5 Y15
G1 Z0.2
G1 X250 E20 F800
G1 Z10

always successful

today i was to late - after last line in startscript G1 Z10, Cura does a diagonal move (XYZ) to startpoint of skirt, i used babystepping while this move was done. That crashed the Z axis completely.

abort the print, do G28: X home ok, Y home ok, Z home - travel to Z-safe-homing-point, no Z move. killed message - reset printer

[emaayan]

yes the issue is still happening, i just tried with marlin 2.0.3, i tried it what my my eternal ball and chain (A.K.A bed leveling model, which is what i've been doing for that last couple of months, printing flat rectangular)

On Sat, Feb 1, 2020 at 5:32 AM Scott Lahteine notifications@github.com wrote:

@emaayan https://github.com/emaayan — If the issue is still occurring, that G-code would be good to check out. Did you ever try reducing the babystep multiplier on your machine, and what value made it work? And, what is your Z steps-per-mm value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/16617?email_source=notifications&email_token=ADGP5MAQPTXYMPLEBES2HM3RATUNBA5CNFSM4KI4O632YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQSPHQ#issuecomment-580986782, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGP5MGXKBUKF2YYRY7LGB3RATUNBANCNFSM4KI4O63Q .

[emaayan]

i should also add that now, even even in spreadcycle mode, after a while the baby stepping mode just hangs, the lcd and z motor stop responding to the knob , but after i stop the print the z axis does respond

On Sun, Feb 2, 2020 at 1:29 AM Elhanan Maayan elh.maayan@gmail.com wrote:

yes the issue is still happening, i just tried with marlin 2.0.3, i tried it what my my eternal ball and chain (A.K.A bed leveling model, which is what i've been doing for that last couple of months, printing flat rectangular)

On Sat, Feb 1, 2020 at 5:32 AM Scott Lahteine notifications@github.com wrote:

@emaayan https://github.com/emaayan — If the issue is still occurring, that G-code would be good to check out. Did you ever try reducing the babystep multiplier on your machine, and what value made it work? And, what is your Z steps-per-mm value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/16617?email_source=notifications&email_token=ADGP5MAQPTXYMPLEBES2HM3RATUNBA5CNFSM4KI4O632YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQSPHQ#issuecomment-580986782, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGP5MGXKBUKF2YYRY7LGB3RATUNBANCNFSM4KI4O63Q .

[emaayan]

my settings:

 */
#define BABYSTEPPING
#if ENABLED(BABYSTEPPING)
  #define BABYSTEP_WITHOUT_HOMING
  //#define BABYSTEP_XY                     // Also enable X/Y
Babystepping. Not supported on DELTA!
  #define BABYSTEP_INVERT_Z false
           // Change if Z babysteps should go the other way
  #define BABYSTEP_MULTIPLICATOR_Z  10
       // Babysteps are very small. Increase for faster motion.
  #define BABYSTEP_MULTIPLICATOR_XY 1

  #define DOUBLECLICK_FOR_Z_BABYSTEPPING
  // Double-click on the Status Screen for Z Babystepping.
  #if ENABLED(DOUBLECLICK_FOR_Z_BABYSTEPPING)
    #define DOUBLECLICK_MAX_INTERVAL 1250
   // Maximum interval between clicks, in milliseconds.
                                            // Note: Extra time may be
added to mitigate controller latency.
    #define BABYSTEP_ALWAYS_AVAILABLE
     // Allow babystepping at all times (not just during movement).
    //#define MOVE_Z_WHEN_IDLE              // Jump to the move Z menu
on doubleclick when printer is idle.
    #if ENABLED(MOVE_Z_WHEN_IDLE)
      #define MOVE_Z_IDLE_MULTIPLICATOR 1
   // Multiply 1mm by this factor for the move step size.
    #endif
  #endif

[Mysel07]

I have similar problem. Babystepping not working after G28, just not move to down. Move to up is OK. The number on the LCD is changing, but the Z-axis motors just twitch. I just turned on function #define BABYSTEP_WITHOUT_HOMING, and I used Babystepping function before G28 immediately after switching on printer, and Babystepping is completely OK. I mean, problem is about G28 - homing. I have SKR 1.3 and TMC2209

• stealtchop is ON or OFF (the same prob),
• steps per mm 400 / 16steps mode

[Mysel07]

I just tried: Change the value of BABYSTEP_MULTIPLICATOR 1-20 TMC2209 steps mode 4,8,16 and steps per mm 100-400 ... still the same problem

[rado79]

today it happend again on a different printer. i did babystepping while a Z move was done. Z axis no more action - had to reset printer. SKR 1.3 TMC2208/2209, bugfix on both printers updated once a week (not same day).

Configuration.zip Configuration_adv.zip

[thinkyhead]

The original issue reminds me that stealthChop has to be on for this failure to occur.

If you find that BABYSTEPPING works with stealthChop turned off, then perhaps it will make sense to turn off stealthChop as a general strategy to ensure good baby-stepping. I'm speculating that maybe the small pulses injected at unusual intervals are not something that stealthChop quite knows how to manage, so the driver itself is going to sleep.

The thing is, Marlin doesn't do anything differently when stealthChop is on or off, so perhaps these SKR boards have some kind of flaw or addition that can't handle out-of-time pulses when stealthChop is enabled.

[thinkyhead]

So, given that pulse timing is the most likely culprit, see if it helps to add this to your config:

#define MINIMUM_STEPPER_PULSE 1

And if that doesn't work, try increasing it to 2 to see if that helps.

[thinkyhead]

Another piece of data that would be useful is to see the output of M122 both before and after the Z stepper driver fails. To get that command in Marlin enable the MONITOR_DRIVER_STATUS option.

[InsanityAutomation]

So, given that pulse timing is the most likely culprit, see if it helps to add this to your config:

#define MINIMUM_STEPPER_PULSE 1

And if that doesn't work, try increasing it to 2 to see if that helps.

Agreed, this sounds very much exactly like the linear advance pulse timing issues that cause them to go into shutdown.

If my memory is correct an increase to 2 helped a little and square wave stepping helps a little. Neither resolved it completely. The large number of steps will definitely make it more likely. It probably only happens on fast mcu's because of how fast they can set the pulses. When a babystep pulse lands right next to a leveling adjustment pulse bad things can happen.

Only way to know for sure is a logic analyzer hooked up but thats what it smells like.

[sjasonsmith]

Agreed, this sounds very much exactly like the linear advance pulse timing issues that cause them to go into shutdown.

Every time I have captured TMC2208 drivers shutting down in Linear Advance, it is immediately preceeded by two or more very rapid pulses, in the middle of a slow pulse train. As an example, imagine two pulses 2us apart, in the middle of a 200us pulse train.

I assume something like this is happening with babystepping, but I'm not exactly sure how it is happening, and I haven't yet captured the failure on an analyzer.

Some possible ideas from the following code:

• _PULSE_WAIT might not properly evaluate to a meaningful delay after my December changes
• MINIMUM_STEPPER_PRE_DIR_DELAY and MINIMUM_STEPPER_POST_DIR_DELAY are not being applied at the end of this macro. That would be fine if the only steps were babystepping, but bed leveling (or other Z movement) could introduce steps immediately after the direction is changed.

  #define BABYSTEP_AXIS(AXIS, INVERT, DIR) {            \
      const uint8_t old_dir = _READ_DIR(AXIS);          \
      _ENABLE(AXIS);                                    \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, _INVERT_DIR(AXIS)^DIR^INVERT);   \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
      _SAVE_START;                                      \
      _APPLY_STEP(AXIS)(!_INVERT_STEP_PIN(AXIS), true); \
      _PULSE_WAIT;                                      \
      _APPLY_STEP(AXIS)(_INVERT_STEP_PIN(AXIS), true);  \
      _APPLY_DIR(AXIS, old_dir);                        \
    }

[sjasonsmith]

It would be great if someone who can reproduce the problem could try replacing that macro (in stepper.cpp) with this version, and re-test.

This isn't perfect. It is going to add some delays that aren't always necessary, and _PULSE_WAIT probably isn't exactly the correct delay for MAXIMUM_STEPPER_RATE, but it should provide some insight.

  #define BABYSTEP_AXIS(AXIS, INVERT, DIR) {            \
      const uint8_t old_dir = _READ_DIR(AXIS);          \
      _ENABLE(AXIS);                                    \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, _INVERT_DIR(AXIS)^DIR^INVERT);   \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
      _SAVE_START;                                      \
      _APPLY_STEP(AXIS)(!_INVERT_STEP_PIN(AXIS), true); \
      _PULSE_WAIT;                                      \
      _APPLY_STEP(AXIS)(_INVERT_STEP_PIN(AXIS), true);  \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, old_dir);                        \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
      _PULSE_WAIT;                                      \
    }

[InsanityAutomation]

Maybe

  #define BABYSTEP_AXIS(AXIS, INVERT, DIR) {            \
      const uint8_t old_dir = _READ_DIR(AXIS);          \
      _ENABLE(AXIS);                                    \
     if(_INVERT_DIR(AXIS)^DIR^INVERT != old_dir) { \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, _INVERT_DIR(AXIS)^DIR^INVERT);   \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
       } \
      _SAVE_START;                                      \
      _APPLY_STEP(AXIS)(!_INVERT_STEP_PIN(AXIS), true); \
      _PULSE_WAIT;                                      \
      _APPLY_STEP(AXIS)(_INVERT_STEP_PIN(AXIS), true);  \
      if(_INVERT_DIR(AXIS)^DIR^INVERT != old_dir) { \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, old_dir);                        \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
        }              \
      _PULSE_WAIT;                                      \
    }

And to minimize impact, maybe bring these down to 200ns instead of the default 650 when used here.

[sjasonsmith]

I recommend just leaving at their defaults. The point is actually to maximize impact. If the behavior improves, then more time can be spent to optimize the solution.

[InsanityAutomation]

Right, but for a tmc the spec is 100ms, so still setting double that. If too many moves get queued up im worried about an overflow as I havnt followed back how theyre queued if at all. But no reason not to try both!

[rado79]

before crash

M122 Log Output

``` Send: M122 Recv: X Y Z Z2 E Recv: Address 0 0 0 Recv: Enabled true true true true false Recv: Set current 700 700 800 800 850 Recv: RMS current 673 673 795 795 826 Recv: MAX current 949 949 1121 1121 1165 Recv: Run current 21/31 21/31 25/31 25/31 26/31 Recv: Hold current 14/31 14/31 17/31 17/31 18/31 Recv: CS actual 14/31 14/31 17/31 17/31 18/31 Recv: PWM scale 15 15 18 19 21 Recv: vsense 1=.18 1=.18 1=.18 1=.18 1=.18 Recv: stealthChop true true true true false Recv: msteps 16 16 16 16 16 Recv: tstep max max max max max Recv: pwm Recv: threshold Recv: [mm/s] Recv: OT prewarn false false false false false Recv: OT prewarn has Recv: been triggered false false false false false Recv: off time 4 4 4 4 4 Recv: blank time 24 24 24 24 24 Recv: hysteresis Recv: -end 2 2 2 2 2 Recv: -start 1 1 1 1 1 Recv: Stallguard thrs 80 40 0 Recv: DRVSTATUS X Y Z Z2 E Recv: stst * * * * * Recv: olb Recv: ola Recv: s2gb Recv: s2ga Recv: otpw Recv: ot Recv: 157C Recv: 150C Recv: 143C Recv: 120C Recv: s2vsa Recv: s2vsb Recv: Driver registers: Recv: X 0xC0:0E:00:00 Recv: Y 0xC0:0E:00:00 Recv: Z 0xC0:11:00:00 Recv: Z2 0xC0:11:00:00 Recv: E 0x80:12:00:00 Recv: Recv: Recv: Testing X connection... OK Recv: Testing Y connection... OK Recv: Testing Z connection... OK Recv: Testing Z2 connection... OK Recv: Testing E connection... OK Recv: ok ```

[rado79]

after Z fail

M122 Log Output

``` Send: M122 Recv: X Y Z Z2 E Recv: Address 0 0 0 Recv: Enabled true true true true false Recv: Set current 700 700 800 800 850 Recv: RMS current 673 673 795 795 826 Recv: MAX current 949 949 1121 1121 1165 Recv: Run current 21/31 21/31 25/31 25/31 26/31 Recv: Hold current 14/31 14/31 17/31 17/31 18/31 Recv: CS actual 14/31 14/31 25/31 25/31 18/31 Recv: PWM scale 14 14 31 30 21 Recv: vsense 1=.18 1=.18 1=.18 1=.18 1=.18 Recv: stealthChop true true true true false Recv: msteps 16 16 16 16 16 Recv: tstep max max 561 561 max Recv: pwm Recv: threshold Recv: [mm/s] Recv: OT prewarn false false false false false Recv: OT prewarn has Recv: been triggered false false false false false Recv: off time 4 4 4 4 4 Recv: blank time 24 24 24 24 24 Recv: hysteresis Recv: -end 2 2 2 2 2 Recv: -start 1 1 1 1 1 Recv: Stallguard thrs 80 40 0 Recv: DRVSTATUS X Y Z Z2 E Recv: stst * * * Recv: olb Recv: ola Recv: s2gb Recv: s2ga Recv: otpw Recv: ot Recv: 157C Recv: 150C Recv: 143C Recv: 120C Recv: s2vsa Recv: s2vsb Recv: Driver registers: Recv: X 0xC0:0E:00:00 Recv: Y 0xC0:0E:00:00 Recv: Z 0x40:19:00:20 Recv: Z2 0x40:19:00:10 Recv: E 0x80:12:00:00 Recv: Recv: Recv: Testing X connection... OK Recv: Testing Y connection... OK Recv: Testing Z connection... OK Recv: Testing Z2 connection... OK Recv: Testing E connection... OK Recv: ok ```

[rado79]

failure is easy to reproduce

define BABYSTEP_ALWAYS_AVAILABLE

G28 doubleclick on controller for babystep menu G1 Z100 meanwhile rotate encoder for babysteps back and forth Z axis no more action

another G28 will home x and y, then M112 is called

[rado79]

before crash, babysteps do hard knocking moves

testing in spreadcycle - works testing Z in spreadcycle and Z2 in stealthchop - only Z2 crashes before crash, babysteps do hard knocking moves

changing BABYSTEP_MULTIPLICATOR_Z to 5 and 2 - crashes Z immediatly if turning encoder BABYSTEP_MULTIPLICATOR to 8 and 12 - requires more babystep moves before crash always knocking while babystepping

[emaayan]

i can also add the using HOMING_FEEDRATE_Z (960) as well as above that (like 1060) with stealthchop will also fail the bltouch (meaning it would home the z, but the probe will retract while the z is still on the bed)

On Wed, Feb 5, 2020 at 10:38 PM rado79 notifications@github.com wrote:

before crash, babysteps do hard knocking moves

testing in spreadcycle - works testing Z in spreadcycle and Z2 in stealthchop - only Z2 crashes before crash, babysteps do hard knocking moves

changing BABYSTEP_MULTIPLICATOR_Z to 5 and 2 - crashes Z immediatly if turning encoder BABYSTEP_MULTIPLICATOR to 8 and 12 - requires more babystep moves before crash always knocking while babystepping

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/16617?email_source=notifications&email_token=ADGP5MGS4N36JQPLDVW4VCTRBMPUDA5CNFSM4KI4O632YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK44TCY#issuecomment-582601099, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGP5MEOBVDENK6I5MI6LK3RBMPUDANCNFSM4KI4O63Q .

[rado79]

It would be great if someone who can reproduce the problem could try replacing that macro (in stepper.cpp) with this version, and re-test…

does not change anything

[sjasonsmith]

does not change anything

Thanks for trying it out! That at least rules out the direction change delay.

[rado79]

Maybe

  #define BABYSTEP_AXIS(AXIS, INVERT, DIR) {            \
      const uint8_t old_dir = _READ_DIR(AXIS);          \
      _ENABLE(AXIS);                                    \
     if(_INVERT_DIR(AXIS)^DIR^INVERT != old_dir) { \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, _INVERT_DIR(AXIS)^DIR^INVERT);   \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
       } \
      _SAVE_START;                                      \
      _APPLY_STEP(AXIS)(!_INVERT_STEP_PIN(AXIS), true); \
      _PULSE_WAIT;                                      \
      _APPLY_STEP(AXIS)(_INVERT_STEP_PIN(AXIS), true);  \
      if(_INVERT_DIR(AXIS)^DIR^INVERT != old_dir) { \
      DELAY_NS(MINIMUM_STEPPER_PRE_DIR_DELAY);              \
      _APPLY_DIR(AXIS, old_dir);                        \
      DELAY_NS(MINIMUM_STEPPER_POST_DIR_DELAY);              \
        }              \
      _PULSE_WAIT;                                      \
    }

And to minimize impact, maybe bring these down to 200ns instead of the default 650 when used here.

tested with these settings

define MINIMUM_STEPPER_POST_DIR_DELAY 20

define MINIMUM_STEPPER_PRE_DIR_DELAY 20

does not change anything

define MINIMUM_STEPPER_POST_DIR_DELAY 200

define MINIMUM_STEPPER_PRE_DIR_DELAY 200

does not change anything

define MINIMUM_STEPPER_POST_DIR_DELAY 650

define MINIMUM_STEPPER_PRE_DIR_DELAY 650

crashes Z immediatly if turning encoder

[sjasonsmith]

@rado79, I want to make sure I understand your last comment. The Z motor stops/crashes with all the settings you tried?

[rado79]

yes crashes always. the only difference is - crashes immediatly if turning encoder - requires more babystep moves before crash

[thinkyhead]

Here are the highlighted differences in the stepper driver statuses…

Before

Recv: PWM scale     15  15  18  19  21
Recv: tstep     max max max max max
Recv: stst      *   *   *   *   *

After

Recv: PWM scale     14      14      31      30      21
Recv: tstep             max     max     561     561     max
Recv: stst              *       *                       *

[thinkyhead]

Check and see if it helps to follow the StealthChop tuning procedure outlined in section 6.2 of the datasheet. We might just need to provide better tuning defaults for some of these axes.

https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC220x_TMC2224_datasheet_Rev1.09.pdf

And also for fun, enable BABYSTEP_XY and see if XY babystepping also leads to the same motor shutdown as Z babystepping.

[thinkyhead]

@sjasonsmith — I foresee a rewrite of Babystepping (which is not very complicated) so that it uses a new methodology. The stepper ISR should just include the extra steps (or leave them out) as part of the stepping phase and we can get rid of this injected and likely out-of-phase step and DIR pulse in the stepper.babystep method.

@rado79 — I would bet that if you have bed leveling turned OFF and start some moves in XY and play around with Z babystepping that the Z stepper will shut down more quickly if you move the knob back and forth to change the DIR pin rapidly. Or, if you are doing a move that includes Z, if you do babystepping in the direction away from Z movement, it probably shuts down faster. I just can't imagine that toggling the DIR pin rapidly makes the driver very happy.

[sjasonsmith]

@thinkyhead I agree with you. I’m trying to find a way to reproduce it very reliably so that I can confirm my suspected root cause with an analyzer, and can have confidence that any fix has solved the problem.

I’m not sure why it is so much harder to reproduce on my printer than others. Perhaps I need to adjust my current up and down and see if that makes it more susceptible.

I’m probably going to wear out my encoder with this one. I went through two batteries on my drill using it to turn the encoder knob last night! I saw about five failures, but nothing consistent enough for me to consider reproducible yet.

[rado79]

@thinkyhead i tried BABYSTEP_XY to get the drivers X and Y to shut down, no chance - works like a charm. I tried the tests above (with G1 Z100 and babysteps), but now only moving babysteps in Z+ direction, no direction change, same issue as above. If i activate UBL, start a print and use babystepping while UBL Z-corretion does his job, i can not reproduce the shut down, and no knocking noise.

@sjasonsmith i do only 1 to 10 clics on encoder until the shut down happens.

[rado79]

@thinkyhead what i did also - disable UBL, start a print and do a lot of rapid back and forth moves with encoder does not show the issue, also no knocking sound while babystepping. So for me there is no issue with direction changes. But this gave me another idea, i started a print with z-hop enabled. Tried to get some babysteps while z-hop, and it did not last long to reproduce the shutdown.

[rado79]

Test with Z feedrate from 1mm/s to 25mm/s does show the issue. Should I do more tests or is it more useful to wait for a rewrite?

[sjasonsmith]

@rado79, probably no more testing is needed on your end for now, unless someone comes up with other experiments to try.

I would like to follow your exact instructions to reproduce the issue. Could you post your updated configs (if different from 3 days ago), as well as the gcode file you are using to reproduce this? My attempts at babystepping during a variety of normal Z moves typically results in noisy steppers but not disabled steppers.

My hope is to come up with some steps that allow me to reproduce it very consistently on my own printer, so that I can capture the signals at the point of failure and see what is going on. Right now we think we know what is happening, but I like to be able to see/measure it to be sure.

[rado79]

Check and see if it helps to follow the StealthChop tuning procedure outlined in section 6.2 of the datasheet. We might just need to provide better tuning defaults for some of these axes.

https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC220x_TMC2224_datasheet_Rev1.09.pdf

@thinkyhead sorry i am not able to do that, normally i fix cars.

[rado79]

@sjasonsmith you can use the config from above, after every test i reversed the changings to my defaults. I do not test with gcode, i do with a single G1 Z100 move or my start script with G1 Z10 at the end because i do not have problems during print (except Z-Hop test from above gcode-Quick_Retraction_Torture_Test.zip).