Duet Stops mid print
-
@BlueDust said in Duet Stops mid print:
when moving at speed
Does it seem to be moving faster than before? With such a high hiccup count it likely wasn't ever actually reaching the full requested speed. You may need to revise your speed assumptions?
Is the squeal coming from the motors?
-
Yes, it seems quicker now. Also, stall guard/sensorless homing seems to be working much better, but have only homed it 3 times so far since the changes....
I think it is is coming from the motors, but need to let the printer run a few minutes to confirm. About to start a small D&D character as a test print I have printed a few times last week (that worked each time I attempted it). Its small so the printer will not get up to any real speeds but should be an easy baseline as it was a recent print.
Thanks!
-
Blue is from last week before x16i and Silver is after. Same code. Very close to the same time too. But as it's small, not able to get up to speed.
Just to make sure it's clear. The issue with my printer stopping was first noticed on a non Palette2 print. I tried many times only using S3d when printing on the Duet2 and having this problem. I shared the Palette2 gcode file as it occured on the same file many times/attempts.
Trying to print that same Palette2 gcode file I shared, right now and it has already gotten past the first time/layer the Duet2 would stop. If it prints another 15 layers without issue, I expect it to finish properly.
Hiccups currently say 0
Thanks! -
-
Glad it's sorted.
-
I think I met you at MRRF 2019.
If your at MRRF 2020, I would like to thank you in person. This problem really ruined a lot of prints.Thanks again!
-
@BlueDust said in Duet Stops mid print:
I think I met you at MRRF 2019.
Yup that was me at the Duet booth. I remember you. MRRF was a lot of fun. Would be great to go again.
-
So.. I haven't been able to actually test this properly, but it used to be if I enabled the magnetic filament sensor after a print started, it would stop the print for lack of movement.
I would have to pause the print, start the filament sensor, and resume the print. Sometimes it would still pause right before the measurements came in, but that wasn't as often.
I started an 8+ hr print with copper filament. I would hate to waste/lose this filament so enabled the Magnetic Filament monitor, but after I started the print (forgot) and it didn't stop the print. I will make sure to test this again to confirm this wasn't a one off fluke, but am now thinking that these Hiccups may have been the cause of most of the abnormal issues/behavior I have been having. Many of which I have asked for help here, on this forum.Thanks again!
-
I had the same issue. Even started a thread on it i think, but it never got resolved. My suspicion was s3d , after i switched to cura i never had that problem again. After i tried s3d again for a specific print and it happened again, i just wrote it off on s3d being weird.
I however had set x16 microstepping with interpolation everywhere, so i doubt it came from that.Edit: Here is the link to my thread with the same issue;
https://forum.duet3d.com/topic/11886/duet-just-stopping-mid-print/8I only had it with s3d and printing thin walled things, the first were lithophanes and the second were some engine covers, all about 2-3mm thick in the xy direction
-
Did you see the M122 you posted shows crazy high Hiccups too?
Hiccups: 10265739
Your hiccups may not have been caused by the same reason as mine, but that may be the problem. I only use S3d or Canvas when I paint a model. I don't remember if I tried using Canvas or not and saw this issue...
I no longer have any Hiccups on my Duet2.
Fun, that 3 letter word with "u" in the middle.
-
@NitroFreak I can't believe I missed the hiccup count in your m122 in that thread.
I suspect that the junky gcode generated by s3d was the cause. When doing things walled objects it inserts a ton of tiny moves (as I pointed out in that thread) to try and print a line thinner than usual. On a slow 8bit marlin board maybe it all gets glossed over by quad stepping. But the duet dutifully tries to execute every single move and gets overwhelmed?
Curse thinwall performance isn't great either. Instead of tiny extrude moves it sometimes tries to use tiny zigzag fill which shakes the hell out of the machine.
Slic3r and (prusaslicer by extension) is the only slicer I've seen that does a decent job of thin walls since it will allow for a variable thickness single line when appropriate rather than trying to vainly enforce a double wall.
-
-
S3D and thinwall:
Interestingly enough, the guys that are making STLs for printing Radio-Control Model Airplanes that fly are very oriented toward S3d. These things print single layer, with their own single layer ribs for structure (no infill). It is quite different from most of the printing that we all do... a unique capability for the printer and unique skill for the human operator.
I do believe they lean toward S3D because of Factory Files, not for anything in the actual slicing. Many MANY parameters must be exactly right, even the orientation on the print stage, to print piece X, and it is often different for different pieces. S3D's factory files encompass all of that. Most slicers do not (or did not about four years ago when these guys got really serious about this) have a way of keeping all that in sync quite as well.
So, no real point to this post in terms of solving anything. Just sort of an FYI on thinwall printing. And, for the record, I still more-or-less dislike S3D.
-
@Danal said in Duet Stops mid print:
MANY parameters must be exactly right
Like wall thickness not being less than nozzle width?
Re factory files, thank goodness the industry appears to have settled on .3MF finally.
-
One wall, right at, or slightly less than, nozzle. Also printed somewhat hot as compared to most printing, so 'current' extrusion melts into 'prior' layer a little bit. PLA at 230 or 240, things like that.
Here's my latest. Extra 550, modeled at 74" wingspan. Plane is about as big as I am. Baseball cap for scale. Haven't flown it yet.
-
Have you somehow solved this problem of blocking?, I can not so fix this problem..
-
@Fedekossel1
Yes, it was resolved.
Run M122 and share your report. That would be the easiest way to tell if you are having the same problem we had. -
@BlueDust
I tried to contact you on twitter, I ran all the procedures you listed, but I couldn't fix -
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SW-6J9FD-3SN6M-TVSZG
Used output buffers: 1 of 24 (15 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 92620 of which 380 recycled
Exception stack ram used: 448
Never used ram: 11912
Tasks: NETWORK(ready,628) HEAT(blocked,1232) MAIN(running,348) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:14:21 ago, cause: power up
Last software reset at 2020-03-08 12:35, reason: User, spinning module GCodes, available RAM 11896 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 10
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 235.7ms, max retries 0
MCU temperature: min 44.3, current 53.0, max 53.2
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 0/99
Driver 1: standstill, SG min/max 0/97
Driver 2: standstill, SG min/max 0/103
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2020-03-08 13:26:45
Cache data hit count 2063208117
Slowest loop: 1256.78ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 363416, FreeDm: 90, MinFreeDm: 84, MaxWait: 306358ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 2350, completed moves: 2310, StepErrors: 0, LaErrors: 0, Underruns: 0, 1
=== 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.3
=== 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 X-23.857 Y19.214 E0.0409" 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: 1257.00ms; fastest: 0.08ms
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 1
WiFi firmware version 1.23
WiFi MAC address ec:fa:bc:31:7e:cd
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23296
WiFi IP address 192.168.43.42
WiFi signal strength -50dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
How did you solve it? I also had microsteps at 256, I took them to 16 interpolated to 256, nothing changed, I also formatted the sd and did tests with other 3 sd, it never solved
