Export GCode in Slic3r stalls

I’m attempting to print my first “rocktopus” and every time I load the STL file in Slic3r and then try to “Export G-code” it begins to export and appears to almost get done but then stalls and never quite finishes exporting the gcode file. I wait for several minutes but nothing. Attached is a screenshot of the progress bar. Does anyone else experience this in Slic3r? Some files export, others don’t. Any suggestions? :confused:

If you open the file during the export process it’s actually exporting the file, albeit rather slowly. What version of Slic3r are you using? Have you tried a different version? You may want to give Cura a try: https://forum.lulzbot.com/t/cura-lulzbot-edition-test-packages/934/1

If you are not using 1.1.7, then turn off “Avoid Crossing Perimeters”.

Kenny

Avoid Crossing Perimeters has always been a problem for my Core 2 Quad PC.

Thanks for that tip, people. Turning off “avoid crossing perimeters” has cut slicing time from tens of minutes down to tens of seconds. Sweet!

Best Regards,
Paul

OK, it seems to be working 100% of the time now on every STL file I try. I am using Slic3r 1.1.7. Perhaps I had a bad file. Some files take a while but most now export in a few seconds.

Agreed with the solution of turning the avoid-cross-borders feature off.

What I found was that on large prints with it turned on, it just took a really REALLY long time. In fact, I set a slicing run a few moments after starting a 20-hour print, and the print finished first. After nearly 34 hours, it horked up a 225MB gCode file. But it did eventually finish. And yes, the printing was ungodly slow because of the constant bizarre paths it would take on movements.

My solution, actually, was to instead use about 1.5 line-heights of Z-lift for moves over like 2-5mm and layer changes. That way I don’t have the banging of nozzle against the part wall during outside-to-inside border crossings (teehee), which after all is (at least partly) why they invented the don’t cross perimeters feature, right?

In my case, when the feature was off, the 225MB file came down to about 30MB, and the print time was easily halved. Note that I never printed the huge file. I figured the chances of 100% success across that much data was effectively zero…for me :wink:.

But now, let me really skewer Slicr here for a moment. You might have found the “number of threads” setting. That works wonderfully during that tiny phase that it’s rendering the shape in memory. During actual slicing, however, the program seems unbelievably stupid about how it goes about it. It uses a single process on a single core. No multi-threading, no parallel-processing, no nothing. And creating a route in a single planar layer…isn’t that like the definition of something fit for a parallel-processing architecture? They are literally separable shapes that given an incoming and outgoing connection point, a completely independent process should be able to do the tool route and then pass it back to the main thread through any number of methods. The main thread’s only work should be to dispatch slice-routing work to individual threads, and then collate the results when they come back, in whatever order they finish. The current method really sux because I am running it on a 16-physical core dual-processor XEON with 16GB of memory. And it’s using just one single core. Plenty of memory, but just one core, chugging along for nearly forever. It looks pathetic on the performance meter, IMO. Oh well, I’m not going to fix it (at least not today or tomorrow), so there’s only so much sense in complaining, right?

Cheers to all,

Thom