Hangs while slicing a specific file

[G-Pereira]

Version

1.41.3

Operating system

Arch Linux (rolling release, always up to date with no white/black lists)

3D printer brand / version + firmware version (if known)

Marlin

Behavior

• Can't slice a specific STL file
• Hangs at generating GCODE (quick slice "Slice Now" works)

Project File (.3MF) where problem occurs is attached

bug.zip

[lukasmatena]

I can confirm that the gcode export hangs with both 1.41.3 and 1.42-beta2. 'Avoid crossing perimeters' seems to be the culprit - turning it off makes the issue disappear.

[BirkBinnard]

G-Pereira - how long did you let it run? Avoid crossing perimeters is known to greatly extend the time required to generate GCode. I've got an STL that I let run for about 10 minutes on an i7-8700 CPU @ 3.2 GHz; it (finally) finished with no problems.

[G-Pereira]

Do you have plans to implement multi-threading?

[BirkBinnard]

Just to see what happens when I turned off Avoid crossing perimeters" I found 2 significant results:

1. Export Gcode time was reduced from about 10 minutes to about 1.
2. The amount of stinging across the interior of my print increases significantly.
   Net result: I'm turning Avid crossing perimeters back on. I can afford to wait for 10 minutes to get a better print that take 20 hours to complete.

G-Pereira: it seems to me that multi-threading would lend itself to any slicer. You could break all the layers into groups with the # layers in each group = the number of CPUs. Then for each group assign each layer to a separate CPU and save the results. When all the groups were processed add the necessary GCode to link them together.

I'm sure it would be more complicated than this, but it seems like a definite possibility.

[guestisp]

Export Gcode time was reduced from about 10 minutes to about 1.

yes, "Avoid crossing perimeters" option slow down a lot the export

[G-Pereira]

it seems to me that multi-threading would lend itself to any slicer.

@BirkBinnard Cura already has multi-threading for almost a year now, and it works great. I think it is really a thing to consider.

[guestisp]

Don't know if it's a multithreading issue, an avoid crossing perimeters issue or whatever, what is sure is that S3D slices almost everything in a couple of second, slic3r needs minutes on certain stl

In example: https://www.thingiverse.com/thing:591330
4-5 seconds with S3D, near a minute with slic3r

[BirkBinnard]

It is fairly easy to see the degree to which any application is multi-threaded. Just open the Windows Resource Manager app (click Start, type resource, and click on the app that pops up.) Then click on the CPU tab. You'll see a series of real-time graphs that show the usage of each CPU in your system.

In my system (Intel i7-8700) the i7 chip has 6 "cores", each with 2 CPUs, for a total of 12. They are numbered 0 - 11. When I slice a large STL file with Ver. 1.41.1 all 12 CPU's go to 100% for the time it takes to complete the slicing operation. This happens fairly quickly. Then the 12 CPUs go to a idle state.

Note that "idle" does not me zero - Windows always has activities going on in the background, and it spreads this activity across all available CPUs.

When I click Export Gcode what happens is a single thread takes over. This thread's CPU activity is spread across most all of the available CPUs in my system - that's a function of Windows itself, but if you look at the aggregate it's pretty clear that the single thread is running at 100% CPU usage.

The fastest slicer I know about is Craftware - Slicing and exporting GCode for the same file is surprisingly quick. The slicing takes only a few seconds and does use all CPUs 100%. (Well, Windows actually keeps 1 CPU for itself and whatever else is going on in the system.) Craftware apparently generates the GCode at the same time it does the slicing because exporting it takes very little CPU resources and happens very quickly.

So it seems there are several factors at play here. One is the slicing and the creation of GCode. Apparently these can be considered as 2 separate and distinct functions, or they can be combined into one. Clearly this is a key design concept for any slicing application.

Whether to use multi-threading or not is obviously another key software design decision. I've got no experience with modern programming languages that have multi-thread capability, but I'm sure there is added complexity to writing software that takes advantage of that.

Finally there is the issue of just what algorithm to use for the slicing and GCode generation. No doubt there are different approaches for these, and some are clearly more efficient than others. Of course efficiency is only one parameter to use for determining which slicer is best for general use.

[bubnikv]

I have fixed a bottleneck in the prepare function to the "avoid crossing perimeters" #2546 #2458 #2631 #2783.

Now this particular model takes roughly 7 minutes to export the G-code with the "avoid crossing perimeters" function enabled, and 1m 40s with the "avoid crossing perimeters" function disabled.

PrusaSlicer is mostly parallelized, with the exception of the G-code generator. There are some reasons why we did not parallelize the G-code generator yet, one of them being, that the start point of the next layer depends on the end point of the previous layer. We will parallelize the G-code export one day though.

Also the "avoid crossing perimeters" feature works currently by calculating Voronoi diagrams of each layer, which is pretty expensive. We may try some tricks, for example to simplify the polygons before the Voronoi diagram is calculated.

[DavidUnboxed]

I tested the 'bug' slice here with the improved slicer. It took about 3-4 minutes for me to slice with "avoid crossing perimeters" running PrusaSlicer-2.1.0-rc2+win64+201909111226 on:

OS Name Microsoft Windows 10 Pro Version 10.0.18362 Build 18362
Processor Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz, 4008 Mhz, 6 Core(s), 12 Logical Processor(s) Installed Physical Memory (RAM) 64.0 GB DDR4
GeForce GTX 1080, NVIDIA compatible /w 8GB DDR5

[bubnikv]

"Avoid crossing perimeters" has been reworked with 5f456eb (see the branch lh_avoid_crossing_perimeters).
The new algorithm will be available in PrusaSlicer-2.3.0-beta3. Please check the PrusaSlicer-2.3.0-beta3 change log for details.