Print stuttering around curves, LaErrors
-
I remember, when i did the 250mm/s test, that it started to judder and slow down randomly at around 280mm/s.
What can cause the processor to overload like that with just 60mm/s? -
@NitroFreak Your video is very reminiscent of problems I had when pressure advance was first introduced. Although, that was with multiple extruders feeding a mixing hot and with much higher PA values than you are using. Still, I wonder if it might be worth disabling PA just to see if it makes any difference or not?
-
@NitroFreak said in Print stuttering around curves, LaErrors:
I dropped the Z axis steps back to x16 and 800 steps /mm. Yes i did use Z hop but i can´t imagine how that would affect a mid layer line.
No I don't think that would cause mid layer issues, but skipping steps on a z hop is a recipe for inaccurate layer heights.
-
@NitroFreak I love that channel! Your values are all a little higher than mine so I may want to change mine. But more importantly, I agree that I thought the 32 bit system should solve this issue. Is there any way to know if its an issue due to extensive mesh facets? I have no hiccups or underruns, and I thought that was where you would see the issue, but I must be mistaken.
-
Do you have another SD card to test with?
-
@Phaedrux Yes, I do have another SD card to test with. I will disable Pressure Advance in the config.g file (I only disabled it mid-print before) and report my findings. My duet is unfortunately buried deep in the printer case (hindsight 20/20, lol) so it may take some time to remove and reinstall the SD.
-
@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, 0
I 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.
-
@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.
-
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.