Movement is stuttering. Appears to slow printing down

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.

Asdasd1234

I'll run a print today without the pressure advance and let you know if still stuttering and will supply the gcode file, thanks

EDIT: Will have to be tomorrow now, I'm out in a bit and wont have time.

EDIT: Ran out of time again, hopefully get some gcode examples up today (12th)

burtoogle

I've submitted a small fix to the Cura devs that stops the small line segments being created when you have curved walls lying immediately adjacent to each other and the overlap compensation is enabled. It should fix the project discussed above but doesn't really tackle the underlying problems that the overlap compensation has. Fixes are currently taking many months to get merged into Cura (assuming it is accepted) so don't expect the official releases to have this anytime soon. The next development version that I release will have this fix in it. See https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0