Print stuttering around curves, LaErrors
-
@Charlie said in Print stuttering around curves, LaErrors:
M566 X480.00 Y480.00 Z30.00 E10000.00 ; Set maximum instantaneous speed changes (mm/min)
The other thing that occurs to me is low Z jerk value and using mesh compensation. I notice your Z jerk is very very low.
-
I tried a saved gcode that was showing the slow down/pauses and it's still doing it, though I didn't have any LAErrors. Just some underruns. At least in the first few layers.
Scheduled moves: 8454, completed moves: 8416, StepErrors: 0, LaErrors: 0, Underruns: 15, 0I resliced the model and printed it again, this time no stutters. The only difference was the Cura build version. The update notes between the two versions says
20200424 - Upstream changes + fix 2 upstream regressions (skirt line print ordering and polygon simplification). 20200328 - Upstream changes + smooth support area outlines to reduce line count (complex outlines will now slice and print faster, gcode size is reduced).Maybe the polygon simplification is the difference here?
-
Try with Cura 4.5.0, the new official version 4.6.0 seems bugged.
-
Underruns are usually caused by one of the following:
- Printing over USB instead of from SD card (most hosts can't supply GCodes fast enough consistently)
- SD card issues. Make sure the SD card is formatted with a high cluster size, preferably 64kb. Also confirm that you are using the built-in SD card of the Duet, because external SD cards use a slower interface.
- Long sequences of very short movements in the GCode. Not usually a problem with modern slicers, but has been in the past especially with Simplify3D.
If you have any small print files that consistent give rise to lookahead errors, please share them.
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 said in Print stuttering around curves, LaErrors:
- SD card issues. Make sure the SD card is formatted with a high cluster size, preferably 64kb. Also confirm that you are using the built-in SD card of the Duet, because external SD cards use a slower interface.
Do you mean the SD card that is in the slot directly on the duet?
I usually use the upload function over DWC, does that put it at the correct location? -
I just sliced the same 100mm circle with cura 4.5 and it works well without stuttering up to 135mm/s, after that the same thing happens.
BUT i used to be able to do it at 250mm/sec.
How is it possible that the code grips the throat of the duet so hard? Especially with the increased maximum resolition and deviation?
Can an external 360 steps/mm stepper really strain the duet so hard?This is the latest M122 with Cura 4.5 and a print speed of between 60 and 180mm/s for the 100mm circle.
How can i reduce the 971000 hiccups?M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F23T0-6J9DJ-3S86S-TWBWD
Used output buffers: 1 of 24 (8 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94004 of which 0 recycled
Exception stack ram used: 444
Never used ram: 10944
Tasks: NETWORK(ready,652) HEAT(blocked,1172) MAIN(running,3748) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:26:33 ago, cause: power up
Last software reset at 2020-04-27 10:32, reason: User, spinning module GCodes, available RAM 11076 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 16
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 393.1ms, max retries 0
MCU temperature: min 26.7, current 40.0, max 42.4
Supply voltage: min 24.3, current 24.6, max 24.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/464
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/243
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2020-04-28 16:22:48
Cache data hit count 4294967295
Slowest loop: 161.60ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 971463, FreeDm: 169, MinFreeDm: 106, MaxWait: 397961ms
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 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.4
=== 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: 394.79ms; 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:52:f6:45
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23328
WiFi IP address 192.168.0.93
WiFi signal strength -63dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
@NitroFreak this is likely because about a year and a few months ago, a change was made to RRF to eliminate the fallback to double/quad stepping when the step pulse generator gets overwhelmed. IE, hiccups are more common now because the system is always running at the set microstepping mode.
Have you configured any axes to be higher than 16x microstepping?
Edit: I see now from your first post that you seem to have 16x enabled on all axes, which should be fine. But, these high speeds are inducing the hiccups. See if you can get away with running 8x microstepping on your x/y axes. (by get away with, I mean if the noise bothers you too much or not)
-
@NitroFreak said in Print stuttering around curves, LaErrors:
@dc42 said in Print stuttering around curves, LaErrors:
- SD card issues. Make sure the SD card is formatted with a high cluster size, preferably 64kb. Also confirm that you are using the built-in SD card of the Duet, because external SD cards use a slower interface.
Do you mean the SD card that is in the slot directly on the duet?
I usually use the upload function over DWC, does that put it at the correct location?Yes it does, unless you change to SD card 1 in Duet Web Control.
-
@NitroFreak said in Print stuttering around curves, LaErrors:
Hiccups: 971463, FreeDm: 169, MinFreeDm: 106, MaxWait: 397961ms
Something isn't right, because if you are using x16 microstepping on all drivers, you should be getting no hiccups, or at most just a few. Please send M350 after printing the 100mm circle and check that it still reports x16 microstepping.
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 -
As an update, I was able to eliminate the stuttering (the banding is likely an issue for another day, lol) by re slicing in Cura 4.5 (Cura 4.6 was where I was having the issues).
Settings are:
No wall overlap compensation
Max resolution: 2.333 mm
Max travel resolution: 0.8 mm
Max deviation: 0.05 mmx16 Microstepping with interpolation
Still had Look Ahead Errors (forgot to copy the M122) but MaxWait was 0 ms.
-
Interesting. Can you inspect the gcode manually and see a vast difference? Are the segment lengths much different?
-
@dc42 said in Print stuttering around curves, LaErrors:
@NitroFreak said in Print stuttering around curves, LaErrors:
Hiccups: 971463, FreeDm: 169, MinFreeDm: 106, MaxWait: 397961ms
Something isn't right, because if you are using x16 microstepping on all drivers, you should be getting no hiccups, or at most just a few. Please send M350 after printing the 100mm circle and check that it still reports x16 microstepping.
Yes it is,
M350
Microstepping - X:16(on), Y:16, Z:16, E:16(on):16(on)But, it reports Y as x16 microstepping while it shouldn´t, i have configured Y as x1 microstepping due to the external drive. But the scale at which Y drives is still correct. so I don´t know?
-
@NitroFreak Ah, I was looking at Charlie's config.g not yours.
The way you write your M350 statement is a bit odd. you comment out the I0 in the first statement. Try refining it into two clear statements like this:
M350 Y1 Z16 ;E16:16I0 ; Configure microstepping without interpolation
M350 X16:16 I1 E16:16 I1 ; Configure microstepping with interpolationM350 Y1 Z16 I0 M350 X16 E16 I1 -
@Charlie said in Print stuttering around curves, LaErrors:
by re slicing in Cura 4.5 (Cura 4.6 was where I was having the issues).
That sounds plausible and would match with the update notes in my custom version being a fix for the issue.
I think @NitroFreak is having a separate issue though. Or at least an additional issue.
-
@bot I was thinking of using a diff checker (any recommended tools would be greatly appreciated) to see what the difference between the two versions may be. I'll update on my findings.
-
@Charlie said in Print stuttering around curves, LaErrors:
I was thinking of using a diff checker (any recommended tools would be greatly appreciated)
Notepad++ on windows, Atom on Mac probably
-
I use Visual Studio Code because it comes with a nicer out-of-the-box config than notepad++ (my former choice). Nice comparison functionality, and an all around great little mini-IDE style text editor.
-
Thank you both for your replies! I tried a normal diff checker, but there was far too much different for me to compare. Using "gcodeanalyser.com" (amazing tool, way better than the "gcode.ws" that I used originally which didn't depict accelerations) I think I found my issue.
First image is using Cura 4.5 (no issues).
Second image is using Cura 4.6 (stuttering issues).
Same exact settings, same layer, but notice how Cura 4.6 speeds up and slows down many more times during the layer. I would assume that it would accelerate once for the layer start, and again for the small radius corner (as in 4.5) but 4.6 changes a lot more.
It's worth noting that the version of Cura that @Phaedrux kindly provided does not appear to have the issues that "stock" Cura 4.6 seems to have.
Please let me know if I'm mistaken with any of my assumptions.
-
@Charlie said in Print stuttering around curves, LaErrors:
Have not seen that one before. I'll have to compare the gcodes and see if I get the same.
-
Unfortunately my 30mb gcode file is choking the analyser and it eventually crashes the page. I'll see if I can find a smaller one that was sliced with that version.
