FAQ Korean Version - slic3r/Slic3r GitHub Wiki
μ΄ λ¬Έμλ Slic3rμ κ΄ν΄ μμ£Ό μ¬λΌμ€λ μ§λ¬Έλ€κ³Ό κ·Έμ λν λ΅λ³μ μ 리ν λ¬Έμμ λλ€.
μλ
Q: G-codeμ μλκ° Slic3rμμ μ€μ ν κ²κ³Ό λ€λ¦ λλ€. μ κ·Έλ΄κΉμ?
A: λ¨Όμ , λΉμ μ΄ Slic3rμμ mm/secμΌλ‘ μλλ₯Ό μ€μ ν λ G-codeλ mm/min λ¨μμ μλλ₯Ό ν¬ν¨νλ€λ κ²μ κΈ°μ΅νμμμ€. κ·Έλ¦¬κ³ , λκ° κ΄λ ¨ μ€μ μ μ μ΄ν΄λ³΄μμμ€(νλΌλ©νΈ λΆλΆ λ°μ μμΉν¨), λκ° μ΅μ μ΄ μΆλ ₯ μλμ μν₯μ λ―ΈμΉ μ μμ΅λλ€.
μ€μ
Q: Save Preset? Export Config? Load Config? νΌλμ€λ½μ΅λλ€.
A: Slic3r version 0.9.0μ μ€μ μ μ μ΄νλ λΆλΆμμ κ°λ Ή κΈ°μ‘΄ νλΌλ©νΈ μ€μ μ 볡μμ μλ‘ λ€λ₯Έ 3D νλ¦°ν°κ°μ μ¬μ¬μ©νκΈ° μ½κ² νλ λ±μ μλ‘μ΄ λ°©λ²μ λμ νμμ΅λλ€. μλ‘μ΄ μ€μ μμ€ν μ μΆλ ₯, νλΌλ©νΈ/νλ¦°ν° μ€μ μ μλ‘ λ€λ₯Έ ν리μ μΌλ‘ λΆλ¦¬νμμ΅λλ€. κΈ°μ‘΄ ν리μ μ μ μ₯νκΈ° μν΄, click on the small diskette button next to the preset name under the given tab.
μμ§ μ΄μ λ²μ μ Slic3r μ€μ λ°©λ²λ File λ©λ΄μμ μ΄μ© κ°λ₯ν©λλ€. κ·Έμ Export Config... μ Load Config... λ₯Ό Slic3rμ νμ¬ μ€μ μ λ΄λ³΄λ΄κΈ°νκ±°λ λ€μ λΆλ¬λ€μ¬μ€λ λ° μ¬μ© κ°λ₯ν©λλ€. 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.
Q: μ μ€μ μ λ΄λ³΄λ΄κΈ°νμλλ°, μ μ₯νμ§ μμλ€λ κ²½κ³ κ° λΉλλ€. μ κ·Έλ°κ°μ?
A: You said 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 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. 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] and [input_filename_base] options will be replaced by the input file name (in the second case, the .stl extension will be stripped). More available variables include [timestamp], [year], [month], [day], [hour], [minute], [second], [version]. When using the graphical interface, [print_preset], [filament_preset], [printer_preset] will be available too. Multi-value options can be called with indices, like [nozzle_diameter_1], [print_center_X], [bed_size_Y].
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.
λ 볡μ‘ν μλ€μ μλλ₯Ό μ°Έκ³ νμΈμ:
[input_filename_base]_h[layer_height]_p[perimeters]_s[solid_layers].gcode [input_filename]center[print_center][layer_height]layers.gcode
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 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]]. 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.)
Calibration
Q: μ μ μΆλ ₯λ¬Όμ μμΉκ° μ ννμ§ μμκΉμ?
A: Have you calibrated Slic3r for your printer? If not, follow the steps outlined in the Calibration guide. Advanced topics
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: 1. 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) 2. 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. Troubleshooting 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.