Prusaslicer: Strange behavior while printing curved perimeters

[uepsie]

Version

1.42-alpha

Operating system type + version

Windows 10 (1809) 64Bit

Behavior

When printing curved perimeters, the mk3 (FW 3.5) slows down extremely and seems to be stuttering. Linear motion is fast.

Using default pla profile and all default settings

[rmoravcik]

@uepsie Is this what you see? I was trying to print some simple objects with new alpha version and I can see some strange artifacts of curved perimeters too.

Here is and example of object (https://www.thingiverse.com/thing:40487) printed using the same settings, same filament, same printer and sliced using the last stable version of Slic3r PE (1.41.2) and new alpha (1.42):

And here are generated gcodes:
Safety_Guard_gcodes.zip

[uepsie]

@rmoravcik yes that's one of the results.
I attached a benchy printed in 0.1 layer height where you can see the artifacts you got too and some other strange artifacts e.g. at the back window

[uepsie]

another thing I noticed it the gcode file is 4 times as big as the one sliced with 1.41 and same settings

[dumski]

I suffer form the same problem. I thought that this is may delta problem firstly, I've examined baud rate (500000 is working ok), set bigger transfer buffers in Marlin (RX_BUFFER_SIZE even to max value of 2048) and playing around with min segment time and segments per second. It doesn't change anything. I've checked GCODE generated by 1.42alpha on my new CoreXY printer and the same bahavior here :(

I've noticed that it's caused by generating way more segments of move per milimeter (even in brim!) than earlier versions: ~10-12 lines of GCODE (moves) per 1mm while earlier versions were generating ~2-3 moves.

I love changes in the last alpha and they convinced me to change my default slicer from Cura to Slic3r. But this issue really affects print quality and printing time so I think it's crucial to fix this bug.

It would be great to have some kind of slider we can adjust a "level of details" in GCODE – like the "Resolution" option but not regarding resolution of input mesh files but "max & min quantity of movements generated per mm".

[dumski]

I've noticed that problem appears also in earlier version. Slic3r 1.41.2stable generates lots of movements in gap fills. This causes same behavior, but only in gap fills and some thin perimeters.

BTW, I attached GCODE generated by this version. Can somebody print it on dry-run mode, to see if this happening on other printers? I have delta and CoreXY, both driven by Mega2560.

pulley10mm-1.41.2.gcode.txt
pulley10mm-1.42alpha.gcode.gcode.txt

[bubnikv]

I fixed a regression bug in Dauglass Peucker contour simplification after an introduction of a non-recursive variant of the algorithm.

Fixed with d0fc4037413cb490c426fcfb6fdc9cd97aa2a0f7
Closing.