Movement is stuttering. Appears to slow printing down

dc42

@asdasd1234 said in Movement is stuttering. Appears to slow printing down:

The XY jerk should be sufficient since just turning off pressure advance allows it to print without stuttering? I'd assume the xy jerk to cause issues in both cases if it were too low?

Yes, that's correct.

burtoogle

@dc42 said in Movement is stuttering. Appears to slow printing down:

@burtoogle said in Movement is stuttering. Appears to slow printing down:

Thanks @asdasd1234 for the comprehensive report and photo. The results are pretty much what I was expecting.

So, the problem is that Cura is generating a mishmash of line segment lengths for the inner walls. The Duet's pressure advance doesn't like that and the result is poor print quality and slowness.

Unfortunately, I do not have a fix for the non-uniform line segment lengths yet but will continue to work on it and will come back to this topic if I make any progress. Fingers crossed.

Having different line segment lengths shouldn't cause a problem for pressure advance, provided that the angles between adjacent segments are small enough to be handled by the allowed XY jerk. What pressure advance has a hard time with is small segments with speed changes or extrusion rate changes from one to the next.

Thanks for that info.

Looking at the gcode, I can see that the short lines do not diverge noticeably from the expected path but because the extrusion amounts are so small, I think there is scope for significant error in the extrusion rate calculation when it is converted into steps/mm.

Sorry, I am not familiar with how RRF handles changes in extrusion rate so this may be a silly question but does it compare the extrusion rates for adjacent line segments after conversion to extruder stepper steps or before? What I'm thinking is that the extrusion rate (mm of filament for mm of travel) could be fairly accurately determined even for very short line segments but after conversion to steps a lot of accuracy could be lost? So the Duet is detecting a bigger change in extrusion rate than is actually being commanded by the gcode?

Here's an example line segment that is very short and so requires a weeny extrusion but the gcode viewer is still reporting the same extrusion rate as the longer line segments that precede and follow the tiddler. So if the gcode viewer can still calculate an accurate mm/mm, can't the Duet do the same for the purposes of deciding whether the rate has changed or not?

That line segment is 0.039 mm long and and the E value is 0.0013 which is most likely going to be less than a extruder step but the rate is still calculable at 0.033 mm/mm.

burtoogle

So, can't the pressure advance calculation use the more accurate extrusion rate value rather than the extruder steps value (if that's what it does now)?

dc42

@burtoogle said in Movement is stuttering. Appears to slow printing down:

So, can't the pressure advance calculation use the more accurate extrusion rate value rather than the extruder steps value (if that's what it does now)?

I am 99% sure that the pressure advance calculation does use the commanded speeds and extrusion amount, before converting the extrusion amount to steps. Except that if the commanded extrusion is less than 1 microstep then it might be treated as a non printing move. Likewise if the commanded X and Y movements are both less than 1 microstep.

burtoogle

@dc42 said in Movement is stuttering. Appears to slow printing down:

@burtoogle said in Movement is stuttering. Appears to slow printing down:

So, can't the pressure advance calculation use the more accurate extrusion rate value rather than the extruder steps value (if that's what it does now)?

I am 99% sure that the pressure advance calculation does use the commanded speeds and extrusion amount, before converting the extrusion amount to steps. Except that if the commanded extrusion is less than 1 microstep then it might be treated as a non printing move. Likewise if the commanded X and Y movements are both less than 1 microstep.

Understood. In that case, is there a benefit to distinguishing between "real" non-printing moves and those that are non-printing because the extruder steps has come out at zero even though the commanded extrusion rate is > 0?

dc42

I'll review the code when I am back in the office.

Asdasd1234

Thanks for looking into it. But do you know of any workaround I can do to mitigate this issue for the time being. I'e, export my model a different way that would avoid whichever triggers are causing it?

burtoogle

@asdasd1234 said in Movement is stuttering. Appears to slow printing down:

Thanks for looking into it. But do you know of any workaround I can do to mitigate this issue for the time being. I'e, export my model a different way that would avoid whichever triggers are causing it?

At this time, I don't have a fix for Cura producing those short line segments so the only workaround I think you have is to disable the pressure advance. Personally, I don't use pressure advance and, generally, don't get ugly layer changes so perhaps there are some other settings you can tweak?

Asdasd1234

Fair enough. The layer changes are most likely just an adjustment to do with retraction priming that I'm sure I can sort easily. I'll turn it off on this model, but I'd like to use it for other models where tolerances are more crucial.

Fingers crossed it get's solved in a future update then

Asdasd1234

@dc42 said in Movement is stuttering. Appears to slow printing down:

I'll review the code when I am back in the office.

Hi,

Did anything come of this in the end? And would increasing the microstepping on my extruder give me a higher upper-speed-limit before hitting this issue since it seems linked to the distance of a single step?
Printing at high speed without pressure advance adds way to much inaccuracy to tolerances for me print without it. I feel like I'm missing out on printing at double the speed at the moment

Many thanks

dc42

It's still on my list for review before I release 2.02RC4. i think there is probably an issue with the code, but whether it is connected with extruder movements less than one microstep, I can't yet say. The code does make allowances for extruding moves sometimes resulting in no actual extruder movement, but I am not sure it allows for that everywhere it needs to.

Meanwhile, I suggest you try increasing extruder microstepping. The only downside is that if you increase it too much, the retraction speed that can be achieved may be reduced.

Asdasd1234

No problem, I've been experimenting yesterday with increasing the microstepping and sticking a larger nema17 motor on my extruder to provide the extra torque for the time being, and I've lucked out finding a setting that's quite a bit faster, and although it still stutters like mad, it at least does the outer wall without stuttering on this particular print, so that'll keep me occupied for now

Many thanks

nophead

@asdasd1234 Do you have control over the number of line segments in the STL file? I have noticed with Cura it will generate ridiculously short segments if the model has them. As I model in OpenSCAD I can simply set $fs to half my extrusion width and then I don't get any segments shorter than 0.25mm. There really isn't any point in printing shorter segments. Skeinforge combines segments that are too small, not sure about other slicers.

burtoogle

@nophead said in Movement is stuttering. Appears to slow printing down:

@asdasd1234 Do you have control over the number of line segments in the STL file? I have noticed with Cura it will generate ridiculously short segments if the model has them. As I model in OpenSCAD I can simply set $fs to half my extrusion width and then I don't get any segments shorter than 0.25mm. There really isn't any point in printing shorter segments. Skeinforge combines segments that are too small, not sure about other slicers.

I have looked at the line segments being produced by Cura for the model discussed above and what is happening is that the outer wall does not contain short line segments but the inner wall does. The inner wall is created from the outer wall by using a clipper library routine. It is that routine that is creating the short line segments. It's really beyond my capabilities to be fixing something like that so I can't really help there, sorry.

Cura does provide a setting that specifies a resolution for the original model but that is not applied to the inner walls. I tried doing that and the results were not satisfactory. More work required.

However, I am waiting with interest to see if David can make any changes that help RRF cope with short line segments when pressure advance is in use.

nophead

@burtoogle Interesting. It is probably a bug in the way Cura is using clipper as offsetting inwards shouldn't generate more line segments in a circle. I never print with more than one wall so I hadn't noticed this.

burtoogle

@nophead , I'll take another look in case I can find any obvious problem...

Asdasd1234

@nophead said in Movement is stuttering. Appears to slow printing down:

@asdasd1234 Do you have control over the number of line segments in the STL file? I have noticed with Cura it will generate ridiculously short segments if the model has them. As I model in OpenSCAD I can simply set $fs to half my extrusion width and then I don't get any segments shorter than 0.25mm. There really isn't any point in printing shorter segments. Skeinforge combines segments that are too small, not sure about other slicers.

Not that I'm aware of. I use fusion 360 for all my parts. The options I get are on this link (https://i.imgur.com/iWAnnjO.png) . All the refinement option does is change the normal/surface deviations.

burtoogle

@asdasd1234 , I have delved into Cura some more and now I think that the problem is actually being caused by the buggy wall overlap compensation and not the clipper lib. So, a simple change for you to try would be to disable the overlap compensation and see what happens. I actually use a modified version of that code because the original is so buggy but it still has problems so it doesn't surprise me that it is generating the spurious short line segments.

burtoogle

I am homing in on the bug(s) but do not yet have a fix.

Another workaround is to set the line width to 0.39 and set fill gaps between walls to nowhere.

dc42

I've just tested the firmware using this script:

G10 P0 S200
M116
G1 X-20 Y0 Z50 F6000
; start extruding
g1 x0 e1 f3000
g1 x2 e0.1
g1 x22 e1
g1 x22.2 e0.01
g1 x42.2 e1
g1 x42.22 e0.001
g1 x62.22 e1
g1 x62.24 e0.001
g1 x82.24 e1
g1 x82.242 e0.0001
g1 102.242 e1

The moves are all designed to have constant extrusion rate from one to the next. Running this test I get no stuttering, with pressure advance set to 0.2 or 0.4.

If I am to attempt a fix in firmware then I need an example of a gcode sequence that causes the stuttering. Preferably, also an analysis (perhaps on a spreadsheet) of:

What the extrusion rate is for each segment;
What the movement direction is for each segment

Has it been established yet whether the problem still occurs with zero pressure advance?

PS - the post by @burtoogle 3 Nov 2018, 13:27 includes an image that shows an example, but I can't copy and paste from that.

PPS adding 0.1mm of Y movement to the 20mm long moves makes no difference, still no stuttering.