Duet Wifi Stepper Driver
-
Hi there
I got a duet wifi from Fillastruder and it was working fine for months. Suddenly neither one of the stepper drivers are working after about 72 of marathon printing. The steppers are working when I test them with other drivers but the drivers for extruders are not responding. How can I fix this?
Thanks
-
Are you sure that the problem isn't that you don't have a tool selected when you try to extrude, or the tool isn't (or doesn't appear to be) up to temperature and you haven't enabled cold extrusion?
Is there any sign of burning on the E0 and E1 stepper driver chips? On the rare occasions when they fail, there is usually a burn mark on top of the chip.
Also, please attempt to extrude using each extruder (so that the drivers are commanded to power up the motors), then run M122 to see what the stepper driver status is.
-
Driver image http://imgur.com/ZRZiTRZ
M122 Log Dump:
[[language]] Diagnostics Used output buffers: 2 of 32 (9 max) Platform Diagnostics: Memory usage: Program static ram used: 13132 Dynamic ram used: 82380 Recycled dynamic ram: 2792 Current stack ram used: 2768 Maximum stack ram used: 3752 Never used ram: 29016 Last reset 00:08:21 ago, cause: software Error status: 0 Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 18.9, current 21.1, max 24.2 Supply voltage: min 12.1, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0 Slowest main loop (seconds): 0.013824; fastest: 0.000122 Move Diagnostics: MaxReps: 1, StepErrors: 0\. Underruns: 0 Heat Diagnostics: Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.4 GCodes Diagnostics: Move available? no Stack pointer: 0 of 5 macro is idle http is ready with "M122" telnet is idle serial is idle aux is idle file is idle Network Diagnostics: WiFiServer is running SPI underruns 0, overruns 0 Webserver Diagnostics: HTTP sessions: 1 of 8 -
Neither were responding and I had the tools selected correctly
-
Unfortunately you are running an old version of the firmware that doesn't display the driver status. The driver chips do not show any sign of damage. Please try the following:
- Upgrade firmware to 1.18.2 and re-run the previous test and M122 report.
- Unload any filament from the extruders, and with the new firmware loaded, send M584 X0:3:4 to make both extruder motors shadow the X axis. Then see whether X movement a!so makes the extruder motors turn.
-
Sorry for the delay. Was away from my printer. Just got the commands sent. I had X on its stepper, E0 on its stepper and Y on the E1 stepper. X and Y seemed to have moved normally but no motion on the E0 extruder.
Diagnostics === Used output buffers: 1 of 32 (16 max) === Platform === Static ram used: 20320 Dynamic ram used: 73000 Recycled dynamic ram: 888 Stack ram used: 968 current, 2940 maximum Never used ram: 33924 Last reset 00:01:55 ago, cause: software Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 33576 bytes (slot 1) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 24.9, current 25.6, max 26.9 Supply voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0, over voltage events: 0 Driver 0: ok Driver 1: standstill Driver 2: standstill Driver 3: open-load-A open-load-B Driver 4: ok Date/time: 2017-06-26 17:28:56 Slowest main loop (seconds): 0.005493; fastest: 0.000320 === Move === MaxReps: 1, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 1, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 Probe change coordinates: === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 1 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 Code queue is empty. === Network === WiFiServer is running SPI underruns 0, overruns 0 === Webserver === HTTP sessions: 2 of 8 -
To eliminate the possibility of a dead stepper I moved the E0 extruder stepper to the x axis and tried it there. It moved nominally.
-
Please do the test I asked for in my previous post.
-
Sorry for the incredibly late reply. I haven't been able to work on it for a while. I ran the test and took a video of what happened. That video is linked here.
In short one of the extruder steppers moves as expected while the other does not want to turn.
