stalling and destroying stepper drivers

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