-
Notifications
You must be signed in to change notification settings - Fork 1.3k
This is a list of frequently asked questions - and answers - regarding Slic3r.
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.
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 --load parameter.
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.
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.
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 slicecommand:
slic3r.pl $s --load config.ini --output $o
and the following under sliceoptscommand:
slic3r.pl --load config.ini --ignore-nonexistent-config
Replace 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:
/Applications/Slic3r.app/Contents/MacOS/slic3r
Whenever you edit your Slic3r configuration from within Pronterface, remember to re-export it using the Export Config... from the File menu.
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] and [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 [nozzle_diameter_1].
More available variables include:
-
[timestamp],[year],[month],[day],[hour],[minute],[second] [version]-
[scale](also as[scale_0],[scale_1]…) -
[print_preset],[filament_preset],[printer_preset](when using the graphical interface) -
[first_layer_temperature_0],[temperature_0] -
[first_layer_bed_temperature],[bed_temperature] [perimeter_speed][fill_density]
The default format is [input_filename_base].gcode, meaning that if you slice a foo.stl file, the output will be saved to foo.gcode.
See below for more complex examples:
[input_filename_base]_h[layer_height]_p[perimeters]_s[solid_layers].gcode
[input_filename]_center[print_center]_[layer_height]layers.gcode
More were documented on the Cartesio wiki, now in new location.
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: [next_extruder], [previous_extruder] (they return the 0-indexed tool number). You can also nest the multi-value variables like this: [temperature_[next_extruder]].
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.
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.)
A: Have you calibrated Slic3r for your printer? If not, follow the steps outlined in the Calibration of Slic3r guide.
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.
The 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:
M203 E2.36
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.
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.