Duet Stops mid print

Phaedrux

@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.

Phaedrux

@BlueDust said in Duet Stops mid print:

Canvas

I believe canvas is based on Kisslicer

Danal

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.

www.3dlabprint.com

alt text

Phaedrux

@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.

Danal

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.

Fedekossel1

Have you somehow solved this problem of blocking?, I can not so fix this problem..

BlueDust

@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.

Fedekossel1

@BlueDust
I tried to contact you on twitter, I ran all the procedures you listed, but I couldn't fix

Fedekossel1

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

Fedekossel1

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

Phaedrux

@Fedekossel1 said in Duet Stops mid print:

=== Move ===
Hiccups: 363416

The hiccup count could be the issue. Using x256 microstepping and having moves faster than the step rate can handle is usually the cause. Using x16 microstepping with interpolation enabled is the solution.

I suggest you start a new thread with your issue. Include your config.g and your M122 output as well.

BlueDust

@Fedekossel1
It appears you may have the same problem as I did with Hiccups and using 256 microstepping.
@Phaedrux helped me fix it. I would follow his advice to help you too.

Good luck!

BlueDust

@Fedekossel1
My Twitter name does not have anything to do with BlueDust as it was already taken. Not sure who you reached out to.

Fedekossel1

I put microsteps at 16 interpolation 256, it still gives me the same problem

Fedekossel1

@BlueDust Did you solve only by changing the microsteps to 16?

BlueDust

@Fedekossel1
Did you update your Motor Steps after you changed it to x16 microstepping?

Per @Phaedrux comment, you should start a new thread, and share your config.g and copy of M122. ( I know you already shared it here, but makes more sense to keep it all together to make it easier to troubleshoot on a new thread).

And yes, changing to x16 microstepping fixed the issue for me. You should make sure to share a new M122 on the new thread after you updating your microstepping to see if you still have a high hiccup count. It was the high hiccup count that caused the issue. It was just 256 microstepping that caused the high hiccup count.
Also, In my case I was printing for over a year before this issue showed itself. I am not sure if it was updated build, or some other changes that made it finally cause problems during a print.

Fedekossel1

@BlueDust This M122 that I posted is already with microsteps, and updated steps to 16 interpolation 256, I will do a new discussion. Thank you