Slic3r wish list  

Re: Slic3r wish list

Hi, I forwarded this topic to Vojtech who is our inhouse developer for Slic3r. He will take a look and try to work in the feedback of everyone.
Before he comes here and start working on things, just quick update:
Driver package 1.7.1 just got released. Slic3r build handles the big objects better. 64 bit version will come in the upcoming week.

Re: Slic3r wish list

Hello Christophe.

Thanks for your feedback.

> - Use separate download from official driver bundle (1.7.x). For now I have a way better stability with the version 1.2.9 and some annoying regression with the last 1.3.x.

Please keep us informed of the regression problems Between Slic3r 1.2.9 and 1.3.0

> Could the Slic3r be outside of the bundle, so that it could be possible to try the last version, and potentially fallback to the 1.2.9 without swaping the complete bundle ?

Yes. We plan to provide the fresh Slic3r builds to the community as zips for the Windows platform, both 32 and 64bit versions are in plan. We have an automatic build system up and running, now we have to set up a public download access.

As a temporary solution, the latest Prusa3d "driver" package will contain a Perl interpreter with a "Large Address Aware" bit set, which means Windows will allow the process to allocate around 2x the memory than without.

> Generating gcode without export: I use to test various setting before choosing the right one to use. For now you can only generate gcode by exporting a file. It would be easier to be able to test various setting first, and once happy exporting the gcode.

You can enable that by going into "Preferences" dialog and enable the "Background processing" checkbox.

> -Fix export to Octoprint: sending gcode directly to octoprint is very handy. In version 1.3 it's broken and crash Slic3r as soon as you try to test the connection. Please fix this very usefull features 🙂

I am aware that the Octoprint support is currently not tested in our Slic3r builds. I had one bug report and I hoped to fix it, but it seems we are not there yet. I have to get an octoprint server up and running to test this feature. I have a Raspberry PI,, but time is the limit.

> - Improving Octoprint export: In addition, being able to edit the filename sent to the octoprint would be very nice. Being able to define filename by using macro, like "%STLNAME%-%Resolution%-%FILAMENTNAME%.gcode" would also be a very nice to have.

I have to make myself familiar with Octoprint first.

> Fix partial layer on top of infill. Typically, when a volume have a partial flat area, this flat first layer does not take in account the underlying infill structure. The result of that is having lines without anything below it to support it. Typical exemplae is the tower of Pi, where a Pi sign is cut in the body of the lower structure. Slic3r typically slice it like that, having many lines starting without any support below it:

We already consider to implement a similar feature. Currently no slicing software does that, the kisslicer being closest: It puts a 50% infill layer below the first top infill layer.

> What I imagine as a solution would be to extend the lines until a proper support can be used from the below layer, something like the picture below. Does that make sense ?

I believe this is exactly the idea I have in my queue already, only it currently does not have a high priority. The regression issues you mentioned sound more important to me.

> -Bridge & Support improvement. I have some difficulty to generate proper support in some cases. I have the feeling the bridging in general have the same kind of flaw in the design, I will try to be more specific later with some example.

Please, provide examples of the flawed bridges.

The supports feature is a candidate for a complete rewrite.

I am happy to receive any useful feedback, which will help me to improve the software.

Thanks, Vojtech

Re: Slic3r wish list

Hi Vojtech,

To test octoprint, since you have a genuine RPi, you can use the Octopi distribution, it's pretty quick to install and everything is allready in the image.

Re: Slic3r wish list

Hi,

One regression I forgot to mention here is that the "slice" button does not do anything, where on 1.2.9 it pop up a new windows letting you slice the part in two piece.

Re: Slic3r wish list

Hi,

One regression I forgot to mention here is that the "slice" button does not do anything, where on 1.2.9 it pop up a new windows letting you slice the part in two piece.

Mmmh, correction, the "cut" button is working, but is way way slower to popup the slicing windows, and the reaction of the slider to adjust the plan used to cut the piece is really very slow.

Re: Slic3r wish list

Hi

Hello Christophe.

> Generating gcode without export: I use to test various setting before choosing the right one to use. For now you can only generate gcode by exporting a file. It would be easier to be able to test various setting first, and once happy exporting the gcode.

You can enable that by going into "Preferences" dialog and enable the "Background processing" checkbox.

Thanks, Vojtech

Regarding this one, even with the "Background processing" checked, I do not see how to generate the gcode without exporting it. Did I miss an additional step ?

[edit] Just found out that it generate slicing while changing printing parameters ... mmmmh, not very handy in my opinion, since changing multiple parameters is then pretty ineficient, I would have prefered a single button, close to the export gcode or export to octoprint, letting me the choice to do the slicing when I'm ready.

Re: Slic3r wish list

I've got a very strange bug with the version included in the 1.7.3 driver bundle, If I try to slice this wonderfull Prusa beer opener, and if I choose 0.10mm detail (and only this resolution show this behavior), the 'a' letter have a strange look, like this:

Re: Slic3r wish list

> Use separate download from official driver bundle (1.7.x).

The standalone Slic3r builds of Prusa3D fork are available on github.
https://github.com/prusa3d/Slic3r/releases

64bit Windows build is available as part of the Prusa3D drivers package as well as through github. In addition, the 64bit Windows build has multi-sample anti-aliasing switched on, which makes the g-code 3D preview nicer.

OctoPrint shall work now. I tested it on Windows.

> Regarding this one, even with the "Background processing" checked, I do not see how to generate the gcode without exporting it. Did I miss an additional step ?
> [edit] Just found out that it generate slicing while changing printing parameters ... mmmmh, not very handy in my opinion, since changing multiple parameters is then pretty ineficient, I would have prefered a single button, close to the export gcode or export to octoprint, letting me the choice to do the slicing when I'm ready.

Partially it is a matter of taste and partially it is quite slow for big objects, because it takes time before the running background calculation is canceled. I may look into it, but the quality of the print has a priority now.

Cutting of an object shall work now. This issue was only specific to a Windows build, probably caused by the changes in the wxWidgets GUI library.

Vojtech

Re: Slic3r wish list

Hi, I confirm that the cut button works properly, Octoprint export works like a breeze, and the 64bits version help a lot with big object.

But Slic3r tend to freeze after a while if you unload and load stl files several times. I wonder if there are some memory leaks. Only way to have a clean behavior is to close it and restart it after slicing a previous STL file.

And do you have an idea what happens during beerbottleopener slicing in 0.10 mm ?

Re: Slic3r wish list

Christophe,

do you have the background processing enabled?

Thanks, Vojtech

Re: Slic3r wish list

I mostly use background processing now, but it seems to occur with this option disabled.

I need to make more test to find something reproductible to investigate, but it seems the freeze is mostly during gcode export phase, note during slicing itself.

And do you have an idea what happens during beerbottleopener slicing in 0.10 mm ? This one is very reproductible 🙂

Re: Slic3r wish list

The Bottle Opener STL file has some of the bottom surfaces of the letters jitering around one of the layer's Z coordinate. In floating point arithmetic, in this case it is hard to guess, if the computer considers these triangles to be below or above the layer Z coordinate. For this model, it helped to change the layer height from 0.1mm to 0.099mm. It produces very much the same result with the same number of layers, but this time the letters are sliced cleanly.

The morale of the story is, the 3D models have to be prepared with the 3D printing technology in mind, including the slicing parameters. I suppose this model was designed by Dominik to be printed with 0.2mm layer height. Indeed, the printed parts are stronger, if printed with thicker layers.

Vojtech

Re: Slic3r wish list

The morale of the story is ...

Don't use floating point arithmetic unless it's absolutely necessary... Unsigned long integers have more than sufficient range to cater for models likely to be sliced. 👿

Peter

Re: Slic3r wish list

The coordinates are stored as floats in the STL file. This is not really an issue of Slic3r, but of the model.

Re: Slic3r wish list

So, when you read the data from the STL file, would it oe possible to convert the values to an unsigned LONG as a (say) 10 micron value, using 5/4 rounding? That should get rid of the issue with this (and many other) models and allow for a maximum model size of over 40 metres.

Just a thought and I appreciate the amount of work involved. I also know that programmers involved in slicing software are exceedingly clever people and, if I were one of them, this sort of thing would annoy the hell out of me!

Anyways, don't spend your time replying, just get on with the job...

Peter

Re: Slic3r wish list

Ok guys,

back to the spirit of this thread 🙂

Some ideas I noted for my wish list:

Regarding support generation:
Additionnal type of support: "Tree-like" support, a bit like MeshMixer can generate support, adding a support that do not start below the supported zone.

Manual tweaking of supports: Ability to edit the zone that should, or should not, have support:

This could be done on the first layer, but it would be more logical to be able to put these force/forbidden zone on the object itself.
The preview tab should show this support zone and forbidden support zone.

Changing parameters by Layer:
It's allready possible to overide some print parameters on object itself, If you want to have different infill when printing multiple object at the same time, but it would be helpfull to override settings by layer, like heatbed/nozzle temperature, infill ratio. The "cut" preview windows should be very helpfull then to define the appropriate layer regarding the object aspect.

Re: Slic3r wish list

A couple of things I'd like to see added are:

By the last I mean the default settings you can select for Print Settings, Filament and Printer. Either by removing the default option altogether or changing their settings to the most basic for the Prusa i3 MK2...

Re: Slic3r wish list

Hello all,

Initially I started a post in the 'Print tips - Slic3r settings...' section of the forum with the title: "Slic3r 1.30.0.25 Bridging...", but seeing how nobody addressed my questions, I am wondering if this is software related, and as such could potentially be addressed by the PR team.

I have two instances:

1. Bridging along the long edge (instead of the short edge) of a perimeter (pic. 1). [This is more inconsistent; sometimes Slic3r bridges well and sometimes it does not, depending on layer height. At the moment I print using the 0.35mm.]

2. Bridging or top-filling an area that is an issue for Slic3r (pic. 2) - I have since tried different settings (i.e. Detect thin walls: off/false) an so far no change to the pictured results.

Also attached are the STL and gcode files.

Hence, I would like to add these to Slic3r wish list.

Thank you.

Reference:
http://shop.prusa3d.com/forum/print-tips-slic3r-settings-kisslicer-model-repair--f12/slic3r-slicer-1-30-0-25-bridging-along-the-long-ed-t1555.html

Re: Slic3r wish list

Hello there!

Today I stumbled over a little issue with slic3r, which has to be added recently: I loaded a big object and, otherwise than with another version, the current one suddenly said:

"Object too big?" -> scaled down automatically.

That is a problem because I use slic3r also to cut my objects. This will now not work anymore. Also, if my object is rotated properly, it is not to big for the printer. But I even cannot rotate it, because: The auto-scale down also takes excessive amount of time while loading (complex object).

My wish is to make this optional - so ask for a scale-down, not just do it and the user has to live with it, rescale it after loading and so on. By the way: After 10 minutes the object still is not loaded so I cannot verify it is even possible to rescale it to a bigger volume than the printer has - maybe it is the also automatically scaled down.

Just.... make it optional please.

Thank you very much,
Marvin Bauch

Additional note to the post above:
Bridging the long side or the short side does not make any difference in the process, because of your infill, which is the same everywhere. In contrary: Bridging the long side will give more stability to your object considering tension legthwise.

EDIT: It could also be a problem with my object... .
EDIT2: It was a problem with my object. It now does not ask me again when loading the copy (although the copy is too big for the printer). All works 🙂