stalling and destroying stepper drivers

Phaedrux

@injoi9000 said in stalling and destroying stepper drivers:

M906 X1600 Y2000 Z0 U0 ; Set motor currents (mA)

You say in your first post you have 2A motors? and it looks like you are using the Y motor at max current? That may be your issue. Is the motor getting very hot? Do you have the board actively cooled with a fan blowing over both sides? Try reducing your Y motor current to 70-85% of max rated current.

Hardware_SortingRobotics

@phaedrux Yup I have 2A motors. My motors only get warm to the touch and I have them mounted to an aluminum block for heat sinking. I have a 80mm 30cfm fan and I have position the duet as a blade in the middle of the fan so i get airflow on top and bottom.

What is the problem with having my motors at 100% max current? That is their rated current right?

Phaedrux

See here: https://duet3d.dozuki.com/Wiki/Choosing_and_connecting_stepper_motors#Section_Rated_current

Hardware_SortingRobotics

@phaedrux So I have read that portion, however, I have several machines run perfectly fine at 100% of rated current and none of my motors get hot. That also doesn't explain how I can pop in a new duet and fix the stalling issues....seems odd.

Phaedrux

Just throwing ideas out there. I would try running at 16 microsteps interpolated at 85% rated current and seeing how that goes. If it still occurs, send M122 to get a diagnostic report and post that here, perhaps that will give another clue.

Hardware_SortingRobotics

@phaedrux Hmm ok I will try that. Thanks for the ideas....it is a tricky problem! Do you have any literature on the effects of running motors at rated current with proper heat sinking?

Phaedrux

@injoi9000 yeah there was actually a discussion about doing exactly that recently.

Here you go.

https://forum.duet3d.com/topic/6797/setting-motor-current-higher-than-rated-current

Do you happen to have an IR thermometer to check the actual motor temps?

For my own 2.0A motors, I know they can get up to 80c if I run them at full current after several hours on a long high speed print. I don't think I was getting any missed steps and there was no stalling. I've added some heatsinking and run at 70% current and the temps are down to 42c. Same performance and a bit quieter.

I'm not exactly sure what your exact application is, or what your mechanics look like, so it's hard to know what else to try. The fact that the problem goes away when you swap the board leads me to wonder what a diagnostic report would say.

Also, which firmware version are you using exactly? Have you checked the recent upgrade notes to see if there have been any bug fixes or changes that might be relevant?

Hardware_SortingRobotics

Ok so I have an update! I just transported my machine 400 miles to a friends house in a uhaul truck and in the first operation the motors stalled. This was after the machine was working continuously For 30 hours! I will run diagnostics on this board but I have a feeling once I swap out the duet everything will work again.....how sensitive is the duet to static electricity or shock/vibration similar to something that might occur during transport?

Hardware_SortingRobotics

I looked at one of the old boards and took a diagnostic of it. Not sure what to look for but here it is.

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6J1FJ-3S06M-K9QRH
Used output buffers: 1 of 20 (1 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 95768 of which 0 recycled
Exception stack ram used: 204
Never used ram: 6624
Tasks: NETWORK(ready,1872) HEAT(blocked,1256) MAIN(running,4488)
Owned mutexes:
=== Platform ===
Last reset 00:01:40 ago, cause: power up
Last software reset at 2018-09-25 13:02, reason: User, spinning module GCodes, available RAM 6364 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
[ERROR] Error status: 0

Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 40.9, current 43.6, max 43.6
Supply voltage: min 0.6, current 1.7, max 1.7, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 1970-01-01 00:00:00
Slowest loop: 0.16ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 0 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.16ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8

WiFi -
Network state is disabled
WiFi module is disabled
Failed messages: pending 2779096485, notready 2779096485, noresp 2779096485
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===

Phaedrux

Was this after a failure?

Hardware_SortingRobotics

@phaedrux This was many power cycles after a failure. Should I send the command immediately after a failure?

Juggeli

It could also be wiring problem. When you swap the board around the connectors and cables get moved around and they are working again. Have you tried to wiggle the connectors and cables when the gantry is moving to see if that has any effect?

I've also had some random stalling problems after assembling my machine and they turned out to be my bad crimp connections.

Phaedrux

@injoi9000 said in stalling and destroying stepper drivers:

@phaedrux This was many power cycles after a failure. Should I send the command immediately after a failure?

Yes. Any error message is reset at a power cycle.

dc42

@injoi9000 said in stalling and destroying stepper drivers:

@phaedrux Yup I have 2A motors. My motors only get warm to the touch and I have them mounted to an aluminum block for heat sinking. I have a 80mm 30cfm fan and I have position the duet as a blade in the middle of the fan so i get airflow on top and bottom.

Can you post a photo of your Duet cooling setup?
Do you ever see temperature warning messages on the GCode Console page of DWC?
Which firmware version are you using?

Hardware_SortingRobotics

@dc42

Picture below
*I have never seen a temperature warning
*I am using firmware version 2.00
*Here is an diagnostic message I received after one of these random stalls:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SN-6JKD2-3S46S-1UYHF
Used output buffers: 2 of 20 (7 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95476 of which 0 recycled
Exception stack ram used: 452
Never used ram: 6764
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3876
=== Platform ===
Last reset 02:24:17 ago, cause: power up
Last software reset details not available
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 60.5ms
MCU temperature: min 13.7, current 21.2, max 24.0
Supply voltage: min 13.8, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-09-28 14:54:25
Slowest loop: 40.42ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 234, MaxWait: 2388690272ms, Underruns: 0, 0
Scheduled moves: 2628, completed moves: 2628
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 70.18ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 84:f3:eb:83:35:c6
WiFi Vcc 3.44, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 14864
WiFi IP address 192.168.1.2
WiFi signal strength -45dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===

alt text

deckingman

@injoi9000 Just looking at that M122......

Supply voltage: min 13.8, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0

So at some point, the supply voltage dropped from around 24v to 13.8v. Just wondering if that is the root cause of the problem - perhaps a dodgy power supply?

Hardware_SortingRobotics

@deckingman

I think that was from me slamming on the E-stop to prevent the misplaced y-axis from destroying my machine... My E-stop is connected to stepper driver power the board is powered by the computer.

adavidm

@injoi9000 Did you see this comment?

@juggeli said in stalling and destroying stepper drivers:

I've also had some random stalling problems after assembling my machine and they turned out to be my bad crimp connections.

If you've got a bad crimp somewhere, or a damaged wire, in the path from duet - > motor then you run the risk of damaging the associated driver. The Duet is better protected against this than most controllers but it sounds like you are working the printer quite hard so maybe it's beyond what the protection can help?

dc42 has a video here demonstrating common failure modes in printer controllers and how the Duet attempts to mitigate them:
https://www.youtube.com/watch?v=uyWolKFzb-A

Hardware_SortingRobotics

@adavidm Hmm...Having a bad crimp could be possible...That might be why the boards get damaged moving from driver to driver. But how come if I swap out a board then the machine works seemingly indefinitely? Maybe the crimps are positioned slightly differently once I swap out the board? How do I tell if I have "bad crimps"?

dc42

Are you certain that the boards are getting damaged, and they don't work again if you let them cool down?
Are they genuine Duet boards purchased from Duet3d.com or from one of our resellers? Genuine TMC2660 chips from Trinamic are now very reliable, but it could be that cloned boards use cloned or reject chips.
As shown in the video, disconnecting motors while under load doesn't normally cause the drivers to fail. OTOH a short circuit across a motor coil, or between one of the motor wires and ground, is much more likely to cause a failure.

HTH David