Duet stops and reboots after extruder action
-
Hello,
i am trying to finaly get my carthesian IDEX working. All set, all wired, everything homes, stops, heats, cools, etc.
I also uploaded the latest firmware, because of weird behaviour, where sometimes, the machine started acting like it has issues with printing. Then had to reboot, run EXACT same g-code, and it worked. So, i updated.
Now, everything still works, until extruder starts/ends first command.
Ie., if i start a S3D gcode, it will heat up, prepare and start that first line. Gets to the end, and Duet stops.
Ok i thought, maybe i did something wrong in Slicer config. Cura. Same thing.
Then i heated everything up, activated tool and extruded 50mm.
It halts and reboots.What am i doing wrong??
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S8-6JKF6-3SN6K-TULVG
Used output buffers: 3 of 24 (7 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94496 of which 0 recycled
Exception stack ram used: 260
Never used ram: 10636
Tasks: NETWORK(ready,648) HEAT(blocked,1236) DUEX(suspended,156) MAIN(running,3780) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:00:51 ago, cause: software
Last software reset at 2019-06-18 09:22, reason: User, spinning module GCodes, available RAM 10636 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 30.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 34.4, current 34.8, max 35.0
Supply voltage: min 24.5, current 24.7, max 24.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-06-18 09:23:49
Cache data hit count 190539260
Slowest loop: 11.67ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 3 is on, I-accum = 0.3
=== 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
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 47.06ms; fastest: 0.00ms
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.23
WiFi MAC address b4:e6:2d:60:31:e0
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24904
WiFi IP address 192.168.0.164
WiFi signal strength -43dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
SOLVED!
Not sure what it was. And i have no patience to wait for it as i need it working.
I backed up all my config files, wiped everything, formatted sd card (just to be sure), reuploaded firmware and reuploaded backup zip with configs.
I guess it was a bad firmware flash from the start. That is probably the reason it took me so long to get it to work in the frst place.
So if anyone experiences this, just backup and wipe everything.
-
I WAS WRONG. NO SOLVED. The crashing came back. Out of nowhere. Was printing fine yesterday, and it does not work today.
What should i do? i changed the SD card, i set IP to DHCP, checked wiring, the voltage is stable...
What is going on??
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S8-6JKF6-3SN6K-TULVG
Used output buffers: 3 of 24 (11 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94532 of which 0 recycled
Exception stack ram used: 260
Never used ram: 10600
Tasks: NETWORK(ready,652) HEAT(blocked,1236) DUEX(suspended,156) MAIN(running,3756) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:00:14 ago, cause: software
Last software reset at 2019-06-20 18:00, reason: Stuck in spin loop, spinning module GCodes, available RAM 10200 bytes (slot 1)
Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20003224 Task 0x454c4449
Stack: 0044a16d 0044a4ce 61000000 a5a5a5a5 0044a16d a5a5a5a5 20003244 200030ec 200048c4 00014f62 20001774 200062ec 20003244 200062e4 00000004 20001788 200030c4 20003244 200030bc 00000001 2000329c 4e49414d 00000000
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 30.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 35.5, current 36.0, max 36.1
Supply voltage: min 24.7, current 24.8, max 24.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-06-20 18:00:58
Cache data hit count 43286501
Slowest loop: 2.55ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -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: 43.92ms; fastest: 0.00ms
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.23
WiFi MAC address b4:e6:2d:60:31:e0
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24784
WiFi IP address 192.168.0.164
WiFi signal strength -41dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
So here i am, writing to myself...
this time (for now), it stopped with complete rewiring and redoing all crimps and clamps and changing the wires from PSU duet and duex. I hope this is what it was initially wrong as i don't think it has anything to do with board and/or firmware..
-
How do you have the Duex wired?
-
@maracmb said in Duet stops and reboots after extruder action:
So here i am, writing to myself...
.....................Not necessarily. A quick gander at the number of views shows that 91 people have taken a look at your post. So the fact that nobody has replied, doesn't mean that people are ignoring you, it just means that nobody has any useful suggestions. Me included....
Clearly it's some sort of intermittent issue and they are always a pain to diagnose. It could be a faulty cable connection somewhere so hopefully you've fixed it. On the other hand, it could be a faulty component somewhere that starts to fail when it reaches a certain temperature. Who knows?
Here is a suggestion. If it happens again, run M122 but otherwise do nothing. Just turn off the power and leave it for a few hours. Then return a few hours later and see if the fault has magically cured itself without you doing anything. If that behaviour persists and you are sure that there are no wiring faults, then you might have a case for suspecting a faulty board which the Duet guys are sure to replace under warrantee - but you need to convince them (and yourself) that it's a faulty board (or component on that board to be more precise). Hence my suggestion that you do nothing other than leave the board unpowered for a while then try again.
-
Maybe it's not useful to you but I had strange problems with mine. I could not understand why, sometimes, he jumped and stamped in the air. I had my doubts about nutrition but with the normal tester the tension was correct. I connected and kept connected an oscilloscope for a few days ..... here it was .... the power supply was crashing from time to time!
I repeat, maybe it is not your case but if you have an oscilloscope working to keep it connected for a while or try another power supply.
Hello! -
Hi all.
I have rewired everything. That was it. I had 105% belief in Duet that it’s not faulty. I do hope it fixed the issue for good and i think i know exact reason: me not puting everithing on a mount and due to using breakout boards not being fixed and cables constantly moved all over during “makeover”, it left those little hairs doing nasty business to thermistor cable (and maybe other places).
Everything looked ok for a freshly assembled proto-mod of chinese base machine, yet it is/was everything but a nice and tidy thing. The box is printing
As i redid the crimping, & replaced AC power switch, all is fine. I didn’t suspect the breakup board of vga cables to printheads early on..
How does it come to a state, when you can make testing, heating, moving etc, but it fails to operate on gcode?
And coincidentaly, couldnt it be a sort of check-up test? -
My guess is that ti was a power problem. Your M122 report indicated stable power, but it also indicated that the Duet had only been running for 14 seconds. If there is a bad power connection so that certain combinations of operations cause the power to fail, that's going to cause the Duet to shut down, whereupon the load on the power supply is greatly reduced, the power comes back up again, and the Duet restarts.
You could write a test GCode file to exercise the motors and heaters, to be run after doing any rewiring. The details of that file will depend on the printer, so we can't supply a standard one.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 thanks for the input.
The short power cycle is due to me trying to post a “clean” report. It could run for hours just heated, homed and ready to execute. It was at the time just after or in time of first gcode extrude execution, so when priming, it rebooted. Only then and when manual extrusion was sent to it. It could sit for hours otherwise.
I suspected the wires of thermistors as both printheads have exact same components, yet the PID values were different. But not that much to be obvious. That alone gave me clue to rewire because wiring truly looked ok.
