Slic3r problem with very thin tall object
Hi,
I am on the way designing something and the prusa 1.3.6 edition of slic3r road blocks me.
It is a very tall and thin object, and slicing it takes some short time but then exporting or sending to octoprint takes ages, well I am not sure if it will end sometime...
Slicer 1.2.9 needs about some seconds to slice AND export. The gcode is under 2MB.
Please check the STL if your slic3r also acts weird. It is just 2 perimeters but tall.
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
For me it is slicing and exporting without issues.
Windows 10 64bit
Sli3r 1.31.6
with the standard profiles
Re: Slic3r problem with very thin tall object
Dang!
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
Problem persists. But Model is canceled due to other reasons. Slic3r under supervision. 😉
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
I am also having issues with slicer taking ages to export the g-code, Prusa Slic3r 1.31.2. At least the status message at the bottom says exporting g-code. Slicing itself takes 30 seconds, exporting takes 10 minutes. I'm on 2011 Macbook Air.
I have heard the setting "ensure vertical shell thickness" can take a lot of computation time, but I don't have this turned on. My part is also very thin, designed to be one extrusion width for the 95% of the part.
Re: Slic3r problem with very thin tall object
Oh ok! But I guess after having it sliced all the "hard" work is done and exporting should be only savng the data to disk or printer. BTW, same result for sending it directly to octoprint. To bad we can't get the bug show up reliably.
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
> It is a very tall and thin object, and slicing it takes some short time but then exporting or sending to octoprint takes ages, well I am not sure if it will end sometime...
> Slicer 1.2.9 needs about some seconds to slice AND export. The gcode is under 2MB.
What operating system?
During the g-code export the paths are ordered, which is non-trivial. The 3D path preview shows the paths before they are ordered, so there is yet some work to be done after that.
Maybe the g-code export takes time due to the OctoPrint connection?
Re: Slic3r problem with very thin tall object
> Slicer 1.2.9 needs about some seconds to slice AND export. The gcode is under 2MB.
What operating system?
During the g-code export the paths are ordered, which is non-trivial. The 3D path preview shows the paths before they are ordered, so there is yet some work to be done after that.
Maybe the g-code export takes time due to the OctoPrint connection?
Windows 8.1 64bit. I am now printing a bed full of snowflakes for decoration (WAF ) and there the slicing takes LONG but no wonder for that type of object. BUT the saving/exporting or sending to octoprint is just a matter of seconds.
Exporting to disk or octoprint is almost the same speed normally but for the specific object it BOTH takes very long. I uploaded 10MB gcode without any flaws (dragon) and in seconds. It is just that object.
Maybe the calculation time just goes up not linear by the number of layers. The object uses all of the Z height. The dragon used only 130mm.
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
@vojtěch.b3
I think I found it! It is "Avoid crossing perimeters". Your mentioning of the ordering made me try that.
Carsten
My Prints: https://www.prusaprinters.org/social/15695-carsten/prints
My Employer: https://make-magazin.de
Re: Slic3r problem with very thin tall object
> I think I found it! It is "Avoid crossing perimeters". Your mentioning of the ordering made me try that.
"Avoid crossing perimeters" is normally off in our settings and it is indeed a deadly bottleneck in the Slic3r performance. And indeed the "avoid crossing perimeters" is executed during the g-code export.