Triple printing time (and low automatic speed) with different model orientation.

[Oscar-KK]

Description of the bug

Just an interesting fact about Prusaslicer's behavior 🙂 When placing this particular model (https://www.printables.com/cs/model/821813-charmander-flexi-articulated-pokemon-print-in-plac) parallel to the pad (as PS automatically puts it there), the calculated resulting print time is about 7:40 and the calculated print speeds are very low. However, just rotate the model by even a single degree or change the size by just one percent (without changing the position) and suddenly the time drops by five hours to about 2:40. However, it must not be rotated 90, 180 and 270 degrees, this is again at 7:40 (only resizing will help there), any other rotation is at 2:40. All this with the same settings (speeds are calculated automatically - max, speed set to 100). I haven't noticed this behavior in other models yet.

Project file & How to reproduce

charmanders.zip

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.7.4.

Operating system

Windows 10

Printer model

Creality Ender 3 S1 + Sonic Pad (Klipper)

[Tupson444]

I've also noticed some inconsistencies in print time, although not as drastic as this example. I first thought that time estimate just isn't reliable, but I tested the files sliced with different time estimates, and they actually printed differently (very close to the estimates), so there is some error in the generated GCODE that unnecessarily makes the print time longer (with the same slicer settings and same STL).

[u89djt]

@Oscar-KK maybe you could edit the report include a 3mf file of it at the alignment that causes the long print time. I can rotate the one you included, or delete and import the stl, and it gives the long slice time. But minimize the number of things the analyst has to get right in a hurry before they can reproduce the effect - they have a long to do list :). I'm some random hobbyist not involved with the work. (P.S. This is the buggest/unluckiest thing I ever saw on here :-D )

I tried switching a bunch of stuff off, and it turns out that this minimum combination of settings causes the long slice:

If you either switch off "detect bridging perimeters", or leave that on and switch to classic perimeter generator in the drop down menu, the time drops to 2h40. Here's a 3mf file of the aligned object and those minimum settings that cause the long slice time at exact alignments with the X and Y axes:
arachne detect bridging aligned PS_Charmander.zip

[murk-sy]

I made the issue reproducible with these 2 layers of a bit of the tail. You can most easily check if the bug is reproduced by enabling speed legend and seeing speeds of ~13. Should be much easier and faster to reproduce now.

Note that the issue does not appear if you make the cutoffs even slightly narrower from any side.

Feature:

Volumetric flow rate:

What I suspect is the culprit:

IMPORTANT: If the model is cut, even if the issue stays reproducible, it may not work after the project is reopened!

Just to spare you some of my own confusion.

Project and sliced gcode in case it's somehow not reproducible again
2024-05-03 Prusaslicer issue 12664 minimised.zip