Duet wifi: printer stalls/stops, no errors
-
Please provide a gcode file that shows this problem, preferably after not many layers, and tell me the approximate layer or object height at which it stalls. Also your config.g file. I will try to reproduce it.
-
the config-files
0_1523349898943_config-override.g 0_1523350166726_config.gand the g-code files via wetransfer (both give the issue here, though every gcode file does currently :P). The printer stalls at around ~1.35mm height (printing at 0.2 layerheight) :
https://we.tl/2hXLfVSJQb -
just did another test: still the same. In the printing module, the layertime keeps counting though. Maybe another clue of some sort.
Also after a firmware reflash: still the same thing
-
I just tried printing your file and it stopped at height 0.3mm. I'm still trying to work out why.
I noticed something odd with that GCode file. You appear to be using firmware retraction, yet the slicer is generating Z hop around the travel moves. Normally if you are using firmware retraction, you should configure the Z hop in the M207 command, not in the slicer.
-
More progress. I noticed that your MaxReps figure was very high (over 900), and on investigation I found that you are using x256 microstepping. A MaxReps figure over 50 is not advisable. So I changed the X and Y microstepping back to x16 with interpolation (after the M92 command, so that the steps/mm gets adjusted properly). Now the print no longer stalls at 0.3mm. As I write this, the print has reached 4.15mm and is still going.
There is still a bug for me to investigate, because even with MaxReps far too high the print shouldn't stall. However, I suspect that your print will complete if you reduce microstepping.
I may eventually implement dynamically varying microstepping, so that you can select x256 and it will be reduced automatically when the speed is high enough to make the step rate too high. But for now I suggest you reduce microstepping. The default of x16 with interpolation works well for most people, but try x32 or x64 instead if you like.
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 you really rock! Thanks for your help, it was driving me mad here haha
It still is very weird that it does print a few layers very nicely (that's how i think i managed to get those numbers so high, it printed fine). Will try your solution now asap. -
@janko said in Duet wifi: printer stalls/stops, no errors:
@dc42 you really rock! Thanks for your help, it was driving me mad here haha
It still is very weird that it does print a few layers very nicely (that's how i think i managed to get those numbers so high, it printed fine). Will try your solution now asap.It might be that the speeds are lower for the first layer, or couple of layers?
-
@t3p3tony it not even might be, they are. However, the feedback i got from printing was a bit mixed. I had one which only did the first layer outline before just stopping. I'm now trying dc42 his solution, see what it brings.
-
Yeah i am sure @dc42's solution is the way to go. I just meant that it could be that the reason it made it part way into the print was that the early layers were printed slower.
-
@t3p3tony it does call for some testing, doesn't it?
After the mount for my psu and my xcarrage has finished, i'll see what happens if i thinker with the layerspeed at 256 microstepping. -
@dc42 your solution is confirmed, tried it on the same file again i sended you, it now continues
-
@janko said in Duet wifi: printer stalls/stops, no errors:
@t3p3tony it does call for some testing, doesn't it?
After the mount for my psu and my xcarrage has finished, i'll see what happens if i thinker with the layerspeed at 256 microstepping.Well it does not hurt to understand what is going on for sure. use the max reps report in the M122 report, rather than waiting for the print to fail.
-
I seem to be having the same issue. First it only happened in the first few layers like in the pictures. Usually in the same spot but not always. I was generally able to just restart the print and have it work fine. However, I just lost one halfway through. The printer just stops, heater and fans are still running and the web interface thinks that the print is still running. It give me the option to pause but nothing happens. Very weird. I have included an m122 readout below. I will reduce the microstepping as you suggest. Just doing my part to help diagnose.
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4S8-6JTDG-3SD6R-13YMX
Static ram used: 16152
Dynamic ram used: 100536
Recycled dynamic ram: 2096
Stack ram used: 1224 current, 6632 maximum
Never used ram: 5656
Last reset 01:30:37 ago, cause: power up
Last software reset at 2018-04-29 01:54, reason: User, spinning module GCodes, available RAM 5656 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x04417000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 126.7ms
MCU temperature: min 19.7, current 30.5, max 31.0
Supply voltage: min 23.7, current 23.8, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/393
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/267
Driver 3: standstill, SG min/max 0/1023
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
Expansion motor(s) stall indication: no
Date/time: 2018-04-30 14:58:10
Slowest main loop (seconds): 0.980719; fastest: 0.000051
=== Move ===
MaxReps: 508091, StepErrors: 0, LaErrors: 0, FreeDm: 121, MinFreeDm 120, MaxWait: 3635039563ms, Underruns: 277, 0
Scheduled moves: 64659, completed moves: 64629
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.8
=== GCodes ===
Segments left: 1
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 doing "G1 X135.148 Y112.675 E0.0579" 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 ===
Responder states: HTTP(1) 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 5c:cf:7f:a4:89:b8
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 15552
WiFi IP address 192.168.1.201
WiFi signal strength -64dBm, reconnections 0, sleep mode modem
Socket states: 2 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0
- WiFi -
-
I believe this issue is fixed in the 2.0beta series firmware. Bete 3 seems to be stable with no known bugs, so please try that version.
