Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This is a list of frequently asked questions - and answers - regarding Slic3r.
Q: The speeds in G-code are different than the ones I configured in Slic3r. Why?
A: First, keep in mind G-code contains speeds in mm/min, while they are expressed in mm/sec in Slic3r. Then, make sure you configured the cooling logic as well (under the Filament section), since the cooling options affect printing speed.
Q: Save Preset? Export Config? Load Config? I'm confused...
A: Slic3r version 0.9.0 introduced a new way of handling configuration which makes it easier to reuse e.g. a given filament configuration with e.g. multiple different printers. The new configuration system separates the settings for printing, filament and printer configuration in separate presets. To save a given preset, click on the small diskette button next to the preset name under the given tab.
The old way of managing Slic3r configuration is still available under the
File menu. Simply use
Export Config... and
Load Config... to export the current configuration from Slic3r and load it back in. This is especially useful for sharing configuration files with somebody else or for exporting a configuration file for use when calling Slic3r from the command-line using the
Q: I exported my configuration, but I get a warning saying I haven't saved it. Why?
A: You said it: you exported the configuration, but you didn't save it into the built-in preset management system (see the question above). You're not required to save it. If you're comfortable with exported, monolithic, standalone config files (just like old Slic3r versions used), feel free to ignore the warning.
Q: Where does Slic3r store its internal configuration files?
A: Slic3r utilizes wxWidgets to store it's internal GUI configuration files. The exact location is platform-dependent and can be found by running
slic3r.pl --debug. Normally, there is no reason to poke around in these files, as they are all managed through the Slic3r GUI. You should probably use
Export Config... from the
File menu instead.
Q: How can I use Slic3r with Pronterface?
A: There are basically two options. The simplest is to use Slic3r stand-alone and load the resulting G-code file directly into Pronterface.
If you're feeling more adventurous, you can have Pronterface call the command-line Slic3r automatically when opening an STL file. To get this to work, you must first export the configuration, you wish to use with Pronterface, from Slic3r using
Export Config... from the
File menu. Next open
Options from the
Settings menu in Pronterface, and put the following under
slic3r.pl $s --load config.ini --output $o
and the following under
slic3r.pl --load config.ini --ignore-nonexistent-config
slic3r.pl with the full path to the Slic3r executable and
config.ini with the full path of your previously exported configuration file. On OS X, the executable has a path like this:
Whenever you edit your Slic3r configuration from within Pronterface, remember to re-export it using the
Export Config... from the
How can I specify a custom filename format for output G-code files?
You can specify a filename format by using any of the config options. Just enclose them in square brackets, and Slic3r will replace them upon exporting. The additional
[input_filename_base] options will be replaced by the input file name (in the second case, the
.stl extension will be stripped). Multi-value options can be called with zero-based indices, like
More available variables include:
[printer_preset](when using the graphical interface)
The default format is
[input_filename_base].gcode, meaning that if you slice a
foo.stl file, the output will be saved to
See below for more complex examples:
What placeholders can I use in custom G-code?
Look at the question above: you can use the same placeholders as the custom output filename format.
In the layer-change and the final (end) custom G-code you can also use
[current_extruder] which returns the 0-indexed tool number.
In the toolchange custom G-code you can also use the following variables which are useful in multi-extruder environments:
[previous_extruder] (they return the 0-indexed tool number). You can also nest the multi-value variables like this:
How can I have my printer start heating after my start G-code procedure is executed?
Just put the heating command(s) in your start G-code, like this:
... other start commands M190 S[first_layer_bed_temperature] M104 S[first_layer_temperature]
Slic3r will detect you used those commands manually and it will not generate any one automatically. Also note that the
 syntax is the placeholder syntax described in previous questions, so it will be replaced automatically by the right values from your configuration without any need to hard-code temperatures.
How can I run custom G-code after heating is complete?
Same as above: if you insert explicit heating commands into your custom G-code Slic3r will not insert them in arbitrary places. This allows you to customize the entire procedure. For example:
... some start commands (for example: park extruder, initialize PID etc.) M109 S[first_layer_temperature] ; wait for temperature ... more start commands (for example: prime extruder etc.)
Q: How come my prints are not dimensionally accurate?
A: Have you calibrated Slic3r for your printer? If not, follow the steps outlined in the Calibration of Slic3r guide.
Q: How can I enforce a volumetric limit for extrusion?
A: If you found what the maximum reasonable extrusion rate your printer can do at a given temperature, you can send a command to your firmware to enforce a limit on it.
There are 2 experimental methods to derive the max extrusion rate:
- print fast, and use live tuning via M221 until you see/feel the filament slipping in the extruder (easy on a standard UM, maybe more difficult on others, and it heavily depends on the extruder mechanism how much pressure it can deliver without slipping)
- extruder calibration routine (either manually in pronterface, or with some to-be-done tool): ask the user to heat up to a middle of the road temp (i.e. 210C for PLA), and push i.e. 20mm filament through the nozzle at a given speed (steps/sec or mm/sec), starting with i.e. 1mm/s, and ask the user "did you feel/see the filament slipping yet, Yes/No, if no, continue increasing the speed by 20%, and ask again. 'Yes" will indicate the max extrusion rate has been reached, and can be saved as mm^3/s, and be displayed as gr/h for user convenience.
M203 command can be used to set the run-time flow rate limit. Just divide your volumetric extrusion limit by (d/2)^2*PI (where d is your filament diameter) and pass the result to
M203. For example, if your limit is 15.6mm^3/sec, supposing you have a 2.9 filament you can send this to your machine:
Marlin will apply the limit and blend your moves so that no extrusion exceeds your max rate.
You can easily include the
M203 command inside the Start G-code in Slic3r to have it automatically prepended to your prints. Note that the firmware uses this limit in a smart way, by blending all your speeds to match it.
Q: Why does the hollow calibration cube fail?
Slic3r honors the configured number of perimeters, so there's no room left for anchoring the bridge. The only way to anchor it would be to automatically reduce the number of perimeters on that layer, but this would violate the configuration provided by the user (the reason the hollow calibration cube is mentioned here and there is because Skeinforge used to reduce perimeters). While this strict design choice of Slic3r might be disappointing, it's actually a very good thing in day-by-day usage, when no hollow cubes need to be printed. We recommend to use a proper calibration model for bridging.
Q: Whenever fan turns on, nozzle gets cooler for a few seconds and extrusion is blocked. How can I handle this?
You could turn the Max Fan Speed setting down in Slic3r, but the best solution is applying a fan duct so that airflow does not affect your nozzle. There's no (clean) way to handle this at the G-code level, and a physical fix is the proper way to go.