Stepper Motors shreaded

[Supastyles]

I purchased this board while it was sold out and received it in late october of the new batch 1.2s

I installed it as I followed the instructions. After a few days with the new board It sounded as if my z motor was binding. I went to work adjusting it to be as smooth as possible. 3 days later I just tried running the motor without the lead screw. Still was making the grinding/binding sounds. I swapped our my Z and my y motors. initially the swapped motor sounder better but not good. and then I tried moving X and Y and Extruder, all were making grinding type sounds. My initial research made me think that I might have unplugged the z motor while live blowing the driver (I dont recall doing this but it's possible as I kept trying different solutions. But this doesn't explain why all the motors would be making noises now. I was only making adjustments to Z.

I swapped back in the OEM board and everything moved but it wasn't smooth or quiet or accurate. Something fried the motors in the 2-3 days after installing the board.

This was confiered today when I bought 1 new motor and moved it around the printer to hear the difference on each point. sounded like a cement mixer before and the normal stepper hum after in all 4 positions.. So I THINK something fried on the board but i KNOW my stepper motors are all fried.

[swilkens]

Initially, the motor current for the stepper motors was pretty high. The manufacturer lists the motor current as the max peak. Not the max continuous.

This was changed in the firmware a while ago, maybe you had an early firmware?

The fix was merged in early september, could be that you had the earlies firmware without the fix.

#25

You could check by connecting to the board and doing M503, it should list the current per axis.

[Thinkersbluff]

I recently made the mistake of walking away from my printer for a day or two, having left my Raspberry Pi powered-up and plugged into the USB port on my BTT SKR Mini e3 v1.2 with the main Ender 3 power supply switch selected to OFF.
I thought nothing of it, until a couple of days later, when I next went to use the printer, I noticed that the motors were all very loudly screeching on every move. I actually burned my finger when I touched one of the motors. They were all hot enough to fry eggs.
Luckily, my system was silent again, after leaving the system fully powered off for a couple of hours. Today, however, I got a TMC Connection Error and the X-axis driver is not driving anything any more.
The Melzi board ran day and night for 10 months with no issues. This board has failed me iafter only a couple of weeks. Clearly, this board is going to require more discipline from me than the original one...
Any chance your issue may also have a connection to having left the USB port powered-up when switching off the printer?

[bojanpotocnik]

... having left my Raspberry Pi powered-up and plugged into the USB port on my BTT SKR Mini e3 v1.2 with the main Ender 3 power supply switch selected to OFF.
... I noticed that the motors were all very loudly screeching on every move. I actually burned my finger when I touched one of the motors. They were all hot enough to fry eggs.

I do not believe USB is the cause of your problem. You can draw maximum 1.2 A from all RPi 3 USB ports combined (source) which is 6 W if you had only the Ender 3 plugged in. That is not even nearly enough to heat any of the stepper motors.

Today, however, I got a TMC Connection Error and the X-axis driver is not driving anything any more.

The same happened to me few weeks ago. X-axis TMC just suddenly died. The only solution was to replace the board.

[Thinkersbluff]

@bojanpotocnik - Thanks for the feedback. I installed my replacement board yesterday, after taping-over the 5v pin on the USB cable and confirming the Pi no longer powers the SKR mini. Today, the X motor got very hot and noisy again. I now have a multi-meter monitoring the touch temperature of the X-axis motor, while I explore various "fixes."
First, I have removed the control box cooling fan guard "upgrade" that I installed to keep debris out of the fan. Installing that seems to reduce the flow of air entering the control box, and the X motor driver is the furthest from the fan so perhaps most likely to overheat if the airflow is insufficient. I'll need a different solution for a fan guard.
Next, I have arbitrarily reduced the motor current for X and Y motors from 580 to 530. The motor is currently running at 27.9 to 28.1 deg C, after an hour of printing in an 18 deg C room. Slightly warm to the touch, but not at all hot. So far, so good.
Do you know whether/how I can configure Marlin 2.0 to use these drivers in CoolStep mode, so that the drivers will automatically reduce the current to the lowest value compatible with the load conditions?

[tgadberry1]

@Thinkersbluff I just experienced a similar issue this morning to what you described in an earlier post. I left my RPi connected to the board with the main printer PSU off over night. I woke up and initiated a simple print before leaving the house, but I thankfully had an itch to check it before leaving. Good thing I did. Something in the room smelled off. “Hot enough to fry eggs” is a spot on description of the XY steppers, and I too burned my finger figuring that out. I’ve only have this board installed for about 5 days, so I’m not sure what’s up (new to the printing scene myself). I’ve decreased my driving current in Marlin from 580 to 530 with some initial luck. I’ll update if that changes. I’m still concerned that the steppers are now a bit louder than previously, where you’d be hard pressed to tell if they we running underneath noise from the stock fans.

Just thankful I didn’t burn my apartment down!

[Thinkersbluff]

My new board is still going strong and my motors never go above warm to the touch, so lowering the drive current to 530 may be a good thing. My other concern for you is whether the electronics box has good cooling. I was doing fine with a "pretty" dust cover over the stock 40mm fan, until I upgraded to the mini. I noticed that although the drivers on the board each have a cooling pad underneath them on the board, the heat sinks are mounted on top of the chips; perhaps where they fit, not where they belong... I decided to put a larger fan in there and installed a fan cover that did not cause the fan to slow down when installed. If your motors are louder when the system warms up, that might be the drivers switching out of Stealthchop mode, as they get hot. Please be sure your cooling is ok. From: [email protected] Sent: March 28, 2020 4:21 PM To: [email protected] Reply-to: [email protected] Cc: [email protected]; [email protected] Subject: Re: [bigtreetech/BIGTREETECH-SKR-mini-E3] Stepper Motors shreaded (#91) @Thinkersbluff<https://github.com/Thinkersbluff> I just experienced a similar issue this morning to what you described in an earlier post. I left my RPi connected to the board with the main printer PSU off over night. I woke up and initiated a simple print before leaving the house, but I thankfully had an itch to check it before leaving. Good thing I did. Something in the room smelled off. “Hot enough to fry eggs” is a spot on, description of the XY steppers, and I too burned my finger figuring that out. I’ve only have this board installed for about 5 days, so I’m not sure what’s up (new to the printing scene myself). I’ve decreased my driving current in Marlin from 580 to 530 with some initial luck. I’ll update if that changes. I’m still concerned that the steppers are now a bit louder than previously, where you’d be hard pressed to tell if they we running underneath noise from the stock fans. Just thankful I didn’t burn my apartment down! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#91 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIW3WXXGTHYCBDLLY3GHPE3RJZL45ANCNFSM4JKRV7RA>.

[tgadberry1]

If your motors are louder when the system warms up, that might be the drivers switching out of Stealthchop mode, as they get hot. Please be sure your cooling is ok.

Are you using an Ender 3 standard or pro?

[Thinkersbluff]

Mine is a standard model, with various upgrades applied by myself. Stock motors, with BTT mini e3 motherboard. When they got hot, they were also quite noisy. Later, I learned that happens when the TMC2209 drivers change operating mode. It can be a sign they are getting hot. From: Ty Gadberry <[email protected]> Sent: March 28, 2020 8:44 PM To: bigtreetech/BIGTREETECH-SKR-mini-E3 <[email protected]> Cc: Thinkersbluff <[email protected]>; Mention <[email protected]> Subject: Re: [bigtreetech/BIGTREETECH-SKR-mini-E3] Stepper Motors shreaded (#91) If your motors are louder when the system warms up, that might be the drivers switching out of Stealthchop mode, as they get hot. Please be sure your cooling is ok. Are you using an Ender 3 standard or pro? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#91 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIW3WXQTTLSWEIQYM3B2UULRJ2KULANCNFSM4JKRV7RA>.

[tgadberry1]

Gotcha. I recently purchased the pro and was immediately concerned about airflow since the only intake is on the bottom of the chassis. Turning the steeper current definitely helped, but I’ll look into printing another electronics case and add another fan. By the way, I tinkered around with the RPi and MB and was able to reproduce the issue after just a few minutes of powering the board via usb with the PSU off. Turning everything back off and letting it cool for about 15 minutes largely resolved this. To avoid any future issues, I added a thin piece of electrical tape to the 5V USB connection on the RPi side to prevent it from independently powering the MB. So far so good.

…

On Mar 28, 2020, 11:04 PM -0500, Thinkersbluff ***@***.***>, wrote: Mine is a standard model, with various upgrades applied by myself. Stock motors, with BTT mini e3 motherboard. When they got hot, they were also quite noisy. Later, I learned that happens when the TMC2209 drivers change operating mode. It can be a sign they are getting hot. From: Ty Gadberry ***@***.***> Sent: March 28, 2020 8:44 PM To: bigtreetech/BIGTREETECH-SKR-mini-E3 ***@***.***> Cc: Thinkersbluff ***@***.***>; Mention ***@***.***> Subject: Re: [bigtreetech/BIGTREETECH-SKR-mini-E3] Stepper Motors shreaded (#91) If your motors are louder when the system warms up, that might be the drivers switching out of Stealthchop mode, as they get hot. Please be sure your cooling is ok. Are you using an Ender 3 standard or pro? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#91 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIW3WXQTTLSWEIQYM3B2UULRJ2KULANCNFSM4JKRV7RA>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[MarekKrzyszton]

Hello there,
I had the same proble with SKR mini 1.2 E3 (motors extremely hot), after searching found this is common issue with this board: losing settings after power failure or recycle.

I have found that TMC drivers get some bizarre (factory default?) settings for much higher current...
I have compiled my Marlin with TMC_debug and checked current mA settings:

These are normal settings (after you set either manually or from firmware recommended 580mA):

Send: M122
Recv: 		X	Y	Z	E
Recv: Address		0	0	0	0
Recv: Enabled		false	false	false	false
Recv: Set current	580	580	580	650
Recv: RMS current	550	550	550	642
Recv: MAX current	776	776	776	905
Recv: Run current	17/31	17/31	17/31	20/31
Recv: Hold current	8/31	8/31	8/31	10/31
Recv: CS actual	8/31	8/31	8/31	10/31
Recv: PWM scale	10	10	10	12
Recv: vsense		1=.18	1=.18	1=.18	1=.18
Recv: stealthChop	true	true	true	true
Recv: msteps		16	16	16	16

and here after power recycle, take look on current RMS, MAX and msteps, totally wrong:

Send: M122
Recv: 		X	Y	Z	E
Recv: Address		0	0	0	0
Recv: Enabled		false	false	false	false
Recv: Set current	580	580	580	650
Recv: RMS current	994	994	994	1160
Recv: MAX current	1402	1402	1402	1636
Recv: Run current	17/31	17/31	17/31	20/31
Recv: Hold current	8/31	8/31	8/31	10/31
Recv: CS actual	31/31	30/31	31/31	31/31
Recv: PWM scale	34	36	36	36
Recv: vsense		0=.325	0=.325	0=.325	0=.325
Recv: stealthChop	true	true	true	true
Recv: msteps		8	8	8	8

M501 restore settings so I have added it to my initial GCode script which run on every printing start.
Hope this helps a little.

BTW: I have removed fan from board inside box. TMC drivers have radiators and checked on long run that inside temperature get no higher than 30C.
It's much quieter now. Of course does not recommend to everybody as there is some potential risk of overheating in some circumstances.

cheers,
Marek

[kaypohl]

@MarekKrzyszton I think I have a similar problem. Before I print, I check with M122 the settings. After 20 minutes of print the X axis motor gets hot and looses steps. M122 results in a much higher RMS current. Don't know how to handle that problem.

[Stieges]

I have also an issue with hot stepper motors. But at the moment i can't find a pattern. Sometimes it is getting hot and sometimes not. When I re-flash it things go well usually. Does anybody found a solution to the "hot stepper motors" problem?

[swilkens]

Recent marlin versions have enabled hybrid threshold by default, which causes the stepper motors to switch from stealthchop to spreadcycle when you go over a limit.

This limit default is set very low for the Z-axis, this caused my Z-stepper to be in spreadcycle constantly - which resulted in a very hot motor.

To fix this, I set the Z-axis threshold much higher.

https://marlinfw.org/docs/gcode/M913.html

[Stieges]

Recent marlin versions have enabled hybrid threshold by default, which causes the stepper motors to switch from stealthchop to spreadcycle when you go over a limit.

This limit default is set very low for the Z-axis, this caused my Z-stepper to be in spreadcycle constantly - which resulted in a very hot motor.

To fix this, I set the Z-axis threshold much higher.

https://marlinfw.org/docs/gcode/M913.html

Thank you for the Information. Can you plz describe me how to do it. 🙈 I am not expert in doing such things

[hnmc20]

Same problem of apparently random stepper overheating (all steppers). It's a fire hazard! It was so hot that one could not touch. I don't know if it's a hardware of software issue, but I'm looking for another board, I mean no more BTT. The parts fan mosfet quit too...

[sms043]

Have the same problem. Stepper current too high X motor loosing steps. The current is set to normal after M501.

[hnmc20]

Have the same problem. Stepper current too high X motor loosing steps. The current is set to normal after M501.

Did you try M122?
I went from my customized firmware to BTT's firmware. I did not try M122 at the time it happened to see what the settings were. M501 retrieves the EEPROM values, but if for some reason the current settings are changed, that does not necessarily implies changes in the EEPROM stored values; as I understand. I'll keep an eye and will provide updates if I find out something.

[sr71shark]

Have the same problem. Stepper current too high X motor loosing steps. The current is set to normal after M501.

Did you try M122?
I went from my customized firmware to BTT's firmware. I did not try M122 at the time it happened to see what the settings were. M501 retrieves the EEPROM values, but if for some reason the current settings are changed, that does not necessarily implies changes in the EEPROM stored values; as I understand. I'll keep an eye and will provide updates if I find out something.

Do I just add this in cura? Or do I add this in the firmware somewhere?

[sr71shark]

Have the same problem. Stepper current too high X motor loosing steps. The current is set to normal after M501.

Did you try M122?
I went from my customized firmware to BTT's firmware. I did not try M122 at the time it happened to see what the settings were. M501 retrieves the EEPROM values, but if for some reason the current settings are changed, that does not necessarily implies changes in the EEPROM stored values; as I understand. I'll keep an eye and will provide updates if I find out something.

Does this get added in cura or in firmware somewhere?

[sr71shark]

Recent marlin versions have enabled hybrid threshold by default, which causes the stepper motors to switch from stealthchop to spreadcycle when you go over a limit.

This limit default is set very low for the Z-axis, this caused my Z-stepper to be in spreadcycle constantly - which resulted in a very hot motor.

To fix this, I set the Z-axis threshold much higher.

https://marlinfw.org/docs/gcode/M913.html

How much higher did you set the hybrid threshold?

[hnmc20]

Recent marlin versions have enabled hybrid threshold by default, which causes the stepper motors to switch from stealthchop to spreadcycle when you go over a limit.
This limit default is set very low for the Z-axis, this caused my Z-stepper to be in spreadcycle constantly - which resulted in a very hot motor.
To fix this, I set the Z-axis threshold much higher.
https://marlinfw.org/docs/gcode/M913.html

How much higher did you set the hybrid threshold?

I just disabled it.

Have the same problem. Stepper current too high X motor loosing steps. The current is set to normal after M501.

Did you try M122?
I went from my customized firmware to BTT's firmware. I did not try M122 at the time it happened to see what the settings were. M501 retrieves the EEPROM values, but if for some reason the current settings are changed, that does not necessarily implies changes in the EEPROM stored values; as I understand. I'll keep an eye and will provide updates if I find out something.

Does this get added in cura or in firmware somewhere

I haven't had the problem with BTT's firmware, yet. Some people set the currents in Cura, this way it's set before each print.

[sr71shark]

For me hybrid threshold is disabled, but I still have this issue. Will try adding M501 and M122 to start gcode in cura

[sr71shark]

I'm having the same issue, and I'm going to detail what I've found that's related here. I have an Ender 3 Pro with BTT Mini E3 v1.2, BMG clone extruder and a 5015 part cooling blower.

ISSUE:

The issue only seems to occur when I leave the power off for a while on the machine. All steppers are louder with a light grinding noise.

THINGS I HAVE TRIED TO SOLVE THE ISSUE:

I have tried setting hybrid threshold higher (500 for all values). I have tried a simple power cycle. I have tried printing something and then power cycle. I have tried leaving the printer off overnight, both plugged in and unplugged. None of this seems to reliably make the issue go away even temporary. However, if I go to Configuration > Store Settings as detailed below, then turn it off and back on within 10 seconds or so, the sound is not there when I turn the printer back on.

TEMPORARY FIX:

After a lot of testing, I found that when I go to Configuration > Store Settings, the issue still happens when any stepper moves. However, if I turn the machine off and then back on relatively soon after going to Configuration > Store Settings, the sound is not there when the steppers move again and the heat issue is gone until I power off the machine for more than a 30 seconds or so. If I do that, the sound is back until I follow the procedure listed above.

POSSIBLE CAUSES:

Is this the firmware? Bad board? PSU Problem? Bad ground maybe?

POSSIBLE SOLUTIONS:

What can be done to eliminate the issue or done as a workaround to keep the issue from returning after powering down for an extended period? Do I need to RMA the board? Fix something in the firmware? Or maybe see if everything is ok with my PSU?

[hnmc20]

I'm having the same issue, and I'm going to detail what I've found that's related here. I have an Ender 3 Pro with BTT Mini E3 v1.2, BMG clone extruder and a 5015 part cooling blower.

ISSUE:

The issue only seems to occur when I leave the power off for a while on the machine. All steppers are louder with a light grinding noise.

THINGS I HAVE TRIED TO SOLVE THE ISSUE:

I have tried setting hybrid threshold higher (500 for all values). I have tried a simple power cycle. I have tried printing something and then power cycle. I have tried leaving the printer off overnight, both plugged in and unplugged. None of this seems to reliably make the issue go away even temporary. However, if I go to Configuration > Store Settings as detailed below, then turn it off and back on within 10 seconds or so, the sound is not there when I turn the printer back on.

TEMPORARY FIX:

After a lot of testing, I found that when I go to Configuration > Store Settings, the issue still happens when any stepper moves. However, if I turn the machine off and then back on relatively soon after going to Configuration > Store Settings, the sound is not there when the steppers move again and the heat issue is gone until I power off the machine for more than a 30 seconds or so. If I do that, the sound is back until I follow the procedure listed above.

POSSIBLE CAUSES:

Is this the firmware? Bad board? PSU Problem? Bad ground maybe?

POSSIBLE SOLUTIONS:

What can be done to eliminate the issue or done as a workaround to keep the issue from returning after powering down for an extended period? Do I need to RMA the board? Fix something in the firmware? Or maybe see if everything is ok with my PSU?

What firmware are you using? What version?
Can you try M122 when the problem happens and post the result.
Have you at least tried the BTT's firmware to see if the problem persists?
I don't really think it's a PSU problem...
I'm assuming you disabled Hybrid Threshold by commenting out #define HYBRID_THRESHOLD in configuration_adv.h, not by increasing the threshold.

[Bakafish]

I'm hitting this issue as well.
I have the: BIGTREETECH-SKR-mini-E3 v1.2
Using the latest "bugfix" branch of Marlin 2
Slicing in Cura
Serving the files from latest version of Octoprint
#define HYBRID_THRESHOLD disabled (tried it enabled as well, but also experienced stepper overheating which brought me here)

The steppers all get super hot, the extruder stepper is using the newer style aluminum frame, and melts the filament prior to entering the Boden tube, causing a jam :-(

I have my print speed dialed down to 25mm/s max, most movement half that value.

M122 output after issue:
Send: M122
Recv: axis:pwm_scale/curr_scale/mech_load|flags|warncount
Recv: X Y Z E
Recv: Address 0 0 0 0
Recv: Enabled false false false false
Recv: Set current 580 580 580 650
Recv: RMS current 994 994 994 1160
Recv: MAX current 1402 1402 1402 1636
Recv: Run current 17/31 17/31 17/31 20/31
Recv: Hold current 8/31 8/31 8/31 10/31
Recv: CS actual 31/31 31/31 31/31 31/31
Recv: PWM scale 175 173 164 71
Recv: vsense 0=.325 0=.325 0=.325 0=.325
Recv: stealthChop true true true true
Recv: msteps 8 8 8 8
Recv: tstep max max max max
Recv: PWM thresh.
Recv: [mm/s]
Recv: OT prewarn false false false false
Recv: triggered
Recv: OTP false false false false
Recv: off time 3 3 3 3
Recv: blank time 36 36 36 36
Recv: hysteresis
Recv: -end -3 -3 -3 -3
Recv: -start 6 6 6 6
Recv: Stallguard thrs 0 0 0 0
Recv: DRVSTATUS X Y Z E
Recv: sg_result 52 56 0 0
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:1F:00:00
Recv: Y 0xC0:1F:00:00
Recv: Z 0xC0:1F:00:00
Recv: E 0xC0:1F:00:00
Recv:
Recv:
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing E connection... OK
Recv: ok

Clearly the steppers are getting too much current.

[Bakafish]

Found this bug: #17981
I did have S_CURVE_ACCELERATION enabled, it wasn't clear that there is a conflict with LIN_ADVANCE

All that this line does is suppress the warning not to use them together:
#define EXPERIMENTAL_SCURVE // Enable this option to permit S-Curve Acceleration

I've therefore disabled S Curve Acceleration and will continue to test with Linear Advance enabled.

[hnmc20]

I'm hitting this issue as well.
I have the: BIGTREETECH-SKR-mini-E3 v1.2
Using the latest "bugfix" branch of Marlin 2
Slicing in Cura
Serving the files from latest version of Octoprint
#define HYBRID_THRESHOLD disabled (tried it enabled as well, but also experienced stepper overheating which brought me here)

The steppers all get super hot, the extruder stepper is using the newer style aluminum frame, and melts the filament prior to entering the Boden tube, causing a jam :-(

I have my print speed dialed down to 25mm/s max, most movement half that value.

M122 output after issue:
Send: M122
Recv: axis:pwm_scale/curr_scale/mech_load|flags|warncount
Recv: X Y Z E
Recv: Address 0 0 0 0
Recv: Enabled false false false false
Recv: Set current 580 580 580 650
Recv: RMS current 994 994 994 1160
Recv: MAX current 1402 1402 1402 1636
Recv: Run current 17/31 17/31 17/31 20/31
Recv: Hold current 8/31 8/31 8/31 10/31
Recv: CS actual 31/31 31/31 31/31 31/31
Recv: PWM scale 175 173 164 71
Recv: vsense 0=.325 0=.325 0=.325 0=.325
Recv: stealthChop true true true true
Recv: msteps 8 8 8 8
Recv: tstep max max max max
Recv: PWM thresh.
Recv: [mm/s]
Recv: OT prewarn false false false false
Recv: triggered
Recv: OTP false false false false
Recv: off time 3 3 3 3
Recv: blank time 36 36 36 36
Recv: hysteresis
Recv: -end -3 -3 -3 -3
Recv: -start 6 6 6 6
Recv: Stallguard thrs 0 0 0 0
Recv: DRVSTATUS X Y Z E
Recv: sg_result 52 56 0 0
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:1F:00:00
Recv: Y 0xC0:1F:00:00
Recv: Z 0xC0:1F:00:00
Recv: E 0xC0:1F:00:00
Recv:
Recv:
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing E connection... OK
Recv: ok

Clearly the steppers are getting too much current.

Does the problem happen when you start printing, after starting, or randomly?
Marlin has a feature to adjust the current when it detects errors. It might be worth a try since your diag shows some ot errors. It seems to be related to how the current is being set by Marlin or the TMC library.
#define MONITOR_DRIVER_STATUS on Configuration_adv.h

[Bakafish]

I didn't do enough print runs to be sure, I changed a lot of variables recently. Switched to Octoprint, left Simplify3D for PrusaSlicer and Cura. In my last setup (using an older custom 2.0 build and Simplify3D via USB) I do not remember any thermal issues with my steppers. After these changes, with the speed dialed way back it seemed like it would be printing fine with no heat, then at some point (after I thought it was working fine) it would jam, and they'd burn me if I checked them. Again, I wasn't doing full isolation as the jam and temps were both things I'm not super enthusiastic about intentionally replicating.

I 100% agree that based on what we are seeing, the current is being ramped up. I disabled the HYBRID_THREASHOLD, but I'm not convinced this was the root cause. I'm pretty sure this feature was in place in the prior config, and as far as I can understand it, switching to spreadCycle is intended to keep the stepper from stalling without having to increase the current. So disabling the feature may actually be exacerbating the issue. At the same time, even though I have had LIN_ADVANCE enabled on all my builds, I never actually changed the value from 0 so it implies that it is disabled when it is set to that. I'm pretty sure that the old config didn't have S_CURVE_ACCELERATION enabled though, and I suspect that it may be part of the issue (maybe compounded by some more obscure settings (jerk?) in the alternate slicers I switched to.)

The critical point is that the current value set in the configuration is being exceeded, and that's a (nasty) bug IMHO. Losing steps and throwing an error is better than melting down. As many people have mentioned, the steppers get at least hot enough to burn you. It's unclear how much damage this could potentially cause... I think some effort needs to be made to track down who is increasing this, and under what conditions, and some logic to prevent it from overdriving the steppers to the point of unsafe (for consumers) temps.

MONITOR_DRIVER_STATUS is enabled on my build, looking through the tmc_util.cpp file, the only thing it will log is if the current is decreased, I'd assume due to over-temp of the drivers. I didn't search exhaustively, but there didn't seem to be any code in there to log anyone increasing the current level, or checks to see if it is being increased beyond the settings. The overcurrent isn't heating up the driver chips themselves though, as I have an 80mm 24v fan on them, and these current levels really aren't pushing them, just these commodity steppers.

[sr71shark]

Ok so for me I have managed to find that my stealthchop was turning off when powered off for over a minute and not turning back on unless I used “store settings” and then did a powercycle.

When you hear the noise, check to be sure stealthchop is turned on. If it is turned off, see if turning it in helps.

For me that didn’t seem to fix it until I turned the printer off and back on within 30 seconds or so. Then no noise until I left it off for too long then turned it back on. This was all with hybrid_threshold disabled in firmware and linear advance enabled.

I discovered that there is a jumper on the board labeled “SPREAD”. There are three pins and the jumper was on the middle pin and right-hand pin (as viewed from the middle of the board looking towards the “SPREAD” jumper. I switched this jumper to the middle pin and the left-hand pin. Then made sure to have stealth chop turned on and hit “store settings” and then powered off. I have left the printer off for over 10 hours two days in a row and haven’t heard the noise since.

From what I’ve gathered, having the jumper in its original orientation as I described above caused the settings to change somehow. Moving it to the new orientation forces stealth chop on when starting up.

So this whole time I’ve been chasing settings issues in Marlin, it’s been a hardware issue.

Can anyone confirm that this fix also works for them? If this works for anyone else I’d be glad to know it’s not just my problem.

[Bakafish]

From what I’ve gathered, having the jumper in its original orientation as I described above caused the settings to change somehow. Moving it to the new orientation forces stealth chop on when starting up.

So this whole time I’ve been chasing settings issues in Marlin, it’s been a hardware issue.

Can anyone confirm that this fix also works for them? If this works for anyone else I’d be glad to know it’s not just my problem.

The incorrect jumper is a known issue on some shipments of the mini board, but the incorrect setting is only is going to force the steppers into a noisier mode of operation, there is no evidence that SpreadCycle mode drastically increases the current usage which causes the overheating. It is not yet clear how this increase of current is happening, some, myself included, g=have seen these settings change due to power cycling the board. As noted above, running the M501 command to reinitialize the driver settings prior to the print job seems like a good short term workaround, but isolating root cause seems pretty critical.

[hnmc20]

As I understand BTT designed the board with 110m ohm Rsense resistors which puts the maximum current between 1.53A-1.77A RMS, this allows a wider selection of stepper motors; what I don't understand is why they went that high, as it exceeds the maximum operational range of the driver and the Ender 3's steppers have a much lower current limit. Anyway, the current needs to be scaled down (pwm_scale) by the software. When doing so, the maximum current can go up to what the Rsense allows. There are also design flaws that could lead to unstable IREF and consequently wrong/spurious current settings. I'm still trying to understand the datasheet...
The parts fan mosfet on my board died and I lost speed control, so I might do some experiments changing the Rsense to match the steppers specs, if I find the specs. The value of these resistors are set in Marlin. This way I know, in theory, that the current won't be higher than what these particular steppers can safely handle. I'm not a programmer, so I can't fix the code, if it's a software bug.

[Bakafish]

Well as previously mentioned it does seem to be some initialization bug. After switching to Octoprint I have the Ender interfaced to a tiny Linux box. That keeps the board powered even when the main PSU is offline, I used to direct connect to my computer (and always disconnected when the printer was not in use.) It looks like the spurious settings are established when the Ender's main power is restored. I did a print last night, and monitored the M122 settings and stepper temps throughout the 5 hour print. Steppers maintained a tepid 38C, and no sign of any driver current changes. Powering it up this morning the settings are bad again. M501 restores them. This makes me think there are two seperate initialization methods, or parameter storage routines that are affected by main power being established. I am a programmer, but I am hesitant to start having to scope out this pretty extensive code base when tracking this down is like 14 Yak shaving layers away from my actual goal of building my pantry, and the M501 workaround will likely resolve this for me.

[hnmc20]

From trinamic.cpp:
// Reduce baud rate for boards not already overriding TMC_BAUD_RATE for software serial.
// Testing has shown that 115200 is not 100% reliable on AVR platforms, occasionally
// failing to read status properly. 32-bit platforms typically define an even lower
// TMC_BAUD_RATE, due to differences in how SoftwareSerial libraries work on different
// platforms.
This is interesting: [https://github.com//issues/22]

[hnmc20]

Well as previously mentioned it does seem to be some initialization bug. After switching to Octoprint I have the Ender interfaced to a tiny Linux box. That keeps the board powered even when the main PSU is offline, I used to direct connect to my computer (and always disconnected when the printer was not in use.) It looks like the spurious settings are established when the Ender's main power is restored. I did a print last night, and monitored the M122 settings and stepper temps throughout the 5 hour print. Steppers maintained a tepid 38C, and no sign of any driver current changes. Powering it up this morning the settings are bad again. M501 restores them. This makes me think there are two seperate initialization methods, or parameter storage routines that are affected by main power being established. I am a programmer, but I am hesitant to start having to scope out this pretty extensive code base when tracking this down is like 14 Yak shaving layers away from my actual goal of building my pantry, and the M501 workaround will likely resolve this for me.

I've noticed something last night: I always power up the printer first and wait for the LCD "printer ready" msg before powering up the raspberry, but I didn't do that yesterday and I had the wrong values loaded (confirmed with M122). I could reproduce by powering up the board with the Pi on twice, and yes the M501 clears it. I think the problem is that the TMC chip's logic is being reset the wrong way, as BTT uses variable 3.3V-5V IO logic and the motors power should be turned ON before the logic. if the Pi is on, the 5V will be there before the VS is applied. It's mentioned here: https://learn.watterott.com/silentstepstick/faq/
Anyway, maybe somebody can confirm if the behavior is reproducible.

[tybit323]

I think I am able to reproduce. If I turn on PS before plugging raspberry pi4 into USB, M122 reports the proper current RPMS/MAX current values. If I swap the order, then they report much higher ~1100-1500 which is way overdriving the stock steppers.

An M501 will restore it.
I'm running the latest 2.0.5.3 BTT Firmware binary

[hnmc20]

I think I am able to reproduce. If I turn on PS before plugging raspberry pi4 into USB, M122 reports the proper current RPMS/MAX current values. If I swap the order, then they report much higher ~1100-1500 which is way overdriving the stock steppers.

An M501 will restore it.
I'm running the latest 2.0.5.3 BTT Firmware binary

Thanks for checking it.

[limestone-xyz]

So I compiled my own firmware, took the settings from the config samples (SKR mini 1.2) and changed some settings according to this guide: https://www.reddit.com/r/ender3/comments/hymv70/marlin_20x_guide_skr_mini_e3_v12_ender_3/

My steppers get really hot to the touch, and the test cube looks really weird - like a staircase, but in z direction: https://photos.app.goo.gl/6XrWJyNCWwzhCtei9
Any thoughts what I could try?

[Bakafish]

So I compiled my own firmware, took the settings from the config samples (SKR mini 1.2) and changed some settings according to this guide: https://www.reddit.com/r/ender3/comments/hymv70/marlin_20x_guide_skr_mini_e3_v12_ender_3/

My steppers get really hot to the touch, and the test cube looks really weird - like a staircase, but in z direction: https://photos.app.goo.gl/6XrWJyNCWwzhCtei9
Any thoughts what I could try?

As I documented above, it is likely that your stepper drivers are running with the wrong (way too high amperage) settings. The root cause of this isn't clear, something isn't getting initialized properly at power up. Putting an M501command in your print initialization script (run before each print) should reset their settings properly and resolve the heating issue which causes the softening of the filament as it moves through the extruder stepper. The heat from the overdriven stepper conducts through the extruder gear and softens the filament, making it slip and jamb, that creates the inconsistent extrusion you see there. I found longer prints (without fixing this issue) will result in serious jambs.

[limestone-xyz]

Thanks for getting back so quickly! I did add the M501 as the first line in CURA before printing the test-cube posted above.
Do I have to put the M501 to a later line? Or do you have any other ides what could be wrong?

[Bakafish]

Well there is a M122 command that outputs the current driver settings, you will need to enable the debugging output by uncommenting #define TMC_DEBUG and rebuilding. The photo you uploaded really looks like issues with proper extrusion to me, and if the steppers get too hot that will cause it (for the reasons I explained above.) Sending the M122 will list output you can compare to the examples above. My steppers do not exceed 40C and can be touched, even during long prints. If you are experiencing anything different than that, either you are hitting the initialization bug, or you may have incorrectly set the default current too high. If the temperature and current are okay, then the next things to check are slipping/dirty extruder gear, a clogged extruder nozzle or loose bowden tube where it meets the hot end, all of which are fairly common on Enders and can cause extrusion issues.

[limestone-xyz]

Thanks for the help!
Yeah I've got debugging active and did check the output of the M122. But I'm not sure where I can see the temps?
The extruder stepper is one of the colder ones (based on my touchy test), the others are way hotter somehow.
M122

[Bakafish]

Those currents look okay, how hot are the steppers getting? Are you running the M122 during the print to confirm they are staying that low? The steppers don't have any temperature sensors, I use a Fluke 62 Max+ optical thermometer, but any thermometer will work. If you are careful you can touch them, but a thermometer gives you a better idea of what they are doing over time.

Seems like you may need to look at the other possibilities I indicated, the extrusion issues or maybe something is wrong with your Z axis slipping? Check the threaded rod and brass nut for slippage or play.

[limestone-xyz]

Ok I probably need to get some sort of temperature sensor then^^
I did another test cube today and the walls are way better (still some stepping though), haven't changed anything.
Maybe it's the ambient temperature of 29°C in the room?
Just reassembled the hotend but couldn't find a clog or jam. Also the extruder doesn't slip and feeds the right amount.
I did an M122 again and these are the current readings:
Recv: X Y Z E
Recv: Address 0 0 0 0
Recv: Enabled false false false false
Recv: Set current 550 550 550 650
Recv: RMS current 939 520 520 642
Recv: MAX current 1324 733 733 905

Idk why only the X stepper draws that much current out of the blue, but the others seem fine.

[hnmc20]

I don't think you need a thermometer. The steppers should not get hot to the point where you can't touch them; at the most warm on long prints. Are you using Octoprint? If so, have you tried to power on the printer and wait for it to be ready and then power up the Raspberry Pi? This worked for me.
My ambient temp is 23C, but I don't think if it'd be that critical with PLA. Were you able to print any good test cube at all? Try re-slicing it and as Bakafish said, make sure your Z axis is moving freely. Disconnect the coupling and make sure it moves freely and smoothly.
Your X motor's current is away off. It never happened to me with only one motor, though. Whenever it happened all of them would be high. Good luck!

[limestone-xyz]

Yeah, I'm first starting the printer and then connecting the cable to the PI, as you've mentioned earlier.
I have no idea why only the X stepper draws that much current. It's also the only one that gets really hot that you can't touch it...
Maybe the stepper is faulty?

[Bakafish]

Agree, something wrong with the X value. The condition I discussed was caused by the extrusion stepper heating to 100C+ causing the filament to soften. That's never going to happen by ambient air. If you do not feel any physical issue with the X stepper's travel, you can swap the X and Y steppers and see if the current abnormality follows the stepper or not. It is conceivable it was damaged by the previous heat issue. Replacements should be cheap if it is the cause.

[hnmc20]

Make sure you wait for the LCD to show printer ready. I could be wrong, but It does not seem to be a stepper problem. The driver is being set to allow a higher current. Re-seat the connectors. You can always try to swap the x and z steppers. One thing that might be worth is to try to print from the SD card without the Pi connected and see if it happens. I don't know if you have tried to re-compile it and re-flash the firmware.

[Piezoid]

I think the problem boils down to the driver resetting their settings to factory defaults when VBB/VS goes down. (See the TMC datasheet the section 17.p71). When you start a print after re-enabling the power supply, the firmware keep it's state via always-on USB power, meaning it won't re-upload the correct setting to the drivers.

Ideally the Marlin firmware should reconfigure the drivers after detecting a VBB power cycle. There is probably no electrical way of detecting this, then it would be board specific.
Another possibility is to be remove the 5V USB supply to the board, either by undersold a diode or modding the USB cable. That way Marlin will reset just after the drivers.

I use the Klipper firmware configured for 64 microsteps, so the problem was obvious when accidentally running with the 16 microsteps default. Still, I had to be physically there to hear the massacre.
Klipper provide a INIT_TMC command to force re-uploading the settings. For Marlin users, M501 seems the way to go. Maybe include it in your print start code ? (you might loose the ability to keep a speed override set before the print).
Personally, I modded the moonraker software (web gateway & system monitor for Klipper) to start klippy service after the on signal to the power supply's relay. This ensure the driver and firmware states are always in sync.

[hnmc20]

I think the problem boils down to the driver resetting their settings to factory defaults when VBB/VS goes down. (See the TMC datasheet the section 17.p71). When you start a print after re-enabling the power supply, the firmware keep it's state via always-on USB power, meaning it won't re-upload the correct setting to the drivers.

Ideally the Marlin firmware should reconfigure the drivers after detecting a VBB power cycle. There is probably no electrical way of detecting this, then it would be board specific.
Another possibility is to be remove the 5V USB supply to the board, either by undersold a diode or modding the USB cable. That way Marlin will reset just after the drivers.

I use the Klipper firmware configured for 64 microsteps, so the problem was obvious when accidentally running with the 16 microsteps default. Still, I had to be physically there to hear the massacre.
Klipper provide a INIT_TMC command to force re-uploading the settings. For Marlin users, M501 seems the way to go. Maybe include it in your print start code ? (you might loose the ability to keep a speed override set before the print).
Personally, I modded the moonraker software (web gateway & system monitor for Klipper) to start klippy service after the on signal to the power supply's relay. This ensure the driver and firmware states are always in sync.

It happens randomly, not necessarily if it's wrongly init. So I believe it to be something beyond an init problem, maybe bad pcb design? I do have the M501 when starting the print. I did remove the 5v usb pwr, but that was recently. I changed the board since then to the SKR mini V2.0 with everything powered from the same PS. I'm still struggling to set it up with some additional mods: UPS, RTD... I also upgraded my steppers, so they'll be able to handle the extra current without burning if it happens and I'm implementing temperature sensors on each stepper. Octoprint has a nice plugin (octoprint enclosure) that allows you to set monitor, set alarms and GPIO actions on the RPi, but I might make something separated from Octoprint, like a safety shut down if temp reaches a certain value. My newer steppers barely get warm. The other option would be to match the sense resistors to the steppers' current so, theoretically it should never get higher than what the hardware allows; but kid of a pain do desolder them though. 0.11ohms Rs exceeds the upper current rating according to the trinamic recommendations (table p.49). I just don't trust to leave it unattended.

[Piezoid]

It happens randomly, not necessarily if it's wrongly init. So I believe it to be something beyond an init problem, maybe bad pcb design? I do have the M501 when starting the print. I did remove the 5v usb pwr, but that was recently. I changed the board since then to the SKR mini V2.0 with everything powered from the same PS.

Ok, that's strange. Maybe the drivers experience brownouts during printing that reset their settings? Does it happen on all the drivers at the same time?

You could check the VBB voltage during print, if you have access to an oscilloscope or a fast multimeter with min/max hold function. I'd try another power supply and/or adding 35V capacitors to the main rail. If it's a pcb design problem, capacitors could also be added closer to the drivers in parallel to the 100µ of each driver. Not sure if it's doable, since they are not through-hole.

So far I didn't find any instability problems with my installation, but I have yet to try multi-days prints. That's why I'm looking preemptively on this kind of issues...

The other option would be to match the sense resistors to the steppers' current so, theoretically it should never get higher than what the hardware allows; but kid of a pain do desolder them though. 0.11ohms Rs exceeds the upper current rating according to the trinamic recommendations (table p.49). I just don't trust to leave it unattended.

Yes, I would have expected from a "mini" board made for ender type machines, to target a lower current range. It would yield better dynamic range for control and less burnt coils.

[hnmc20]

Maybe the drivers experience brownouts during printing that reset their settings? Does it happen on all the drivers at the same time?_

• I don't know if it's a brownout issue. I'd have to monitor the power to tell if there's a power glitch.

Does it happen on all the drivers at the same time?

• The SKR mini uses UART to scale down the current from the +- 1.8A set by the Rs, and when it happens if you run the M122 you'll see that the scaling factor went all the way up, so someway something changes the register. UART glitch? If you check trinamic's layout example, BTT does not follow the VS filtering, capacitors... anyway, hard to tell what is going on.

Yes, I would have expected from a "mini" board made for ender type machines, to target a lower current range. It would yield better dynamic range for control and less burnt coils.

• I think they wanted to cover all possible uses, just pushed beyond the recommended and the PCB copper they used does not allow the necessary heat dissipation (mini v1.2) they seem to have beefed it up on the v2.0 though.