seems like excessive time to generate g-code

Hi,
Just getting to know my new printer and have been printing some simple items. I decided to try a pen holder with an abstract shape
but after 2 hours of trying to generate g-code,i cancelled the effort. The green fill in the status bar moves right along until about 90% but then just hangs
I'm using Slic3r
Thanks for any help in advance,

Peter

Slic3r takes forever to export the gcode (I assume that is what slic3r is doing at 90%). Just keep waiting...

Checking "avoid crossing perimeters" cause the code to generate very slowly. I still use it, but it does take much longer using 1.1.7 I found that 1.2.5 was MUCH faster but it won't print small perimeters correctly on the first layer. So I still use 1.1.7 and wait for the code.

---

Socrates ~ The Amsterdamman
slic3r-1.2.9

My 1.2.0 was working pretty well, but it choked and locked up on a simple key-chain item- and that was with the crossing perimeters set correctly. I don't know what it is that makes it go so slow. I almost feel like some setting gets goofy, the code gets corrupted or something and instead of an error you never get the G code. Re-installing and starting from scratch for settings has helped in the past.

I had a STL (large one) that took 21 seconds to produce output in Cura, but took 735 minutes, 43 seconds in Slic3r. Yes, that's 12 hours. Ack. And, I did have it set to avoid crossing perimeters, but had the same setting in Cura as well. In certain cases, I really prefer the Slic3r output on the printer, but that amount of time to slice is ... well, long.

Quote
triplanedave
I had a STL (large one) that took 21 seconds to produce output in Cura, but took 735 minutes, 43 seconds in Slic3r. Yes, that's 12 hours. Ack. And, I did have it set to avoid crossing perimeters, but had the same setting in Cura as well. In certain cases, I really prefer the Slic3r output on the printer, but that amount of time to slice is ... well, long.

Yes, there is quite obviously a bug in the "avoid crossing perimeters" mode that causes Slic3r to take a ridiculously long time to slice anything other than extremely simple STLs. I have also had Slic3r churning away overnight, but unchecking that box resulted in the same STL taking a few seconds to slice. Cura does not have that bug, but is far less versatile in many other areas. For me, Cura's biggest deficiency is that it cannot detect bridges - although the last Slic3r version I used was not particularly clever in that regard either, because it laid down the first bridging layer over a gap that was 5mm wide and 150mm long in the long direction! Simplify3D is better in that regard in that it will always bridge across the shortest distance, even if that means bridging several different gaps in different directions on the same layer. But S3D does not honour the bridging speed parameter when laying a bridging perimeter (only uses bridging speed for bridging infill), so it seems that at present there is no application that does not have shortcomings with bridging.

Dave

I have found there are usually other problems that accompany long slice times with Slic3r. It won't save changes I've made to settings, etc. When I see that behavior I reinstall slic3r and it seems to fix things until the next time slic3r pukes. Slic3r has been doing this under windows and linux for me for a couple years and I've never found an explanation anywhere. Maybe some obscure dll gets updated, breaking slic3r,.. IDK. I have talked to other who have had the same problem, so it isn't just my installation or the way I am slicing things. This is why I switch back and forth between Cura and Slic3r.

I have found the most reliable way to run slic3r is to compile from source code under linux. Cura seems much more stable and a little smarter about generating support material, but I like slic3r's ability to control every other little detail of the print.

This thing about slic3r not responding to changes in settings... is it for really small adjustments that are hard to notice, or for the entire program?

When Slic3r doesn't save changes to settings, any setting, you're going to have a problem. For example, you change the number of perimeters from 3 to 2, then save the print settings, and the number changes back to 3. This sort of behavior can happen with any of the settings in any of the preset files. When you see that sort of behavior, Slic3r is going to fail to produce gcode or is going to produce bad gcode. You can fix the problem by deleting the preset files and recreating them. Slic3r will then behave itself for a while.

I previously said repairing Slic3r required reinstall. When you wipe and reinstall, the presets get recreated and Slic3r works again. A complete reinstall isn't necessary- just delete the presets and recreate them.

I used to run multiple threads because my computer has a multicore CPU. Bad idea. Leave it run in a single thread. With multiple threads, multiple copies of the part get copied to memory, and unless you have a LOT of memory (I have 12 GB and it still pukes), it will cause the machine to slow down and frequently Slic3r will fail to deliver gcode.

Also, under print settings> advanced> resolution- if you have a very detailed STL file, leaving resolution set to zero can slow down or even cause slicing to fail. Set that value to 0.02 or some similar small value and slicing will speed up.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

.02 mm ?