Ultimaker Slicing Page

Slic3r

Currently Slic3r doesn't seem designed very well for the Bowden cable design on our printer. Really what is needed is better firmware that correctly does the calculations to do a good print from standard gcode (which is what all modern CNC machines do) and there are some projects in the wild that are attempting this.

In the mean time, Slic3r causes "plastic pimples" from where it pauses between layer changes and also has problems with "stringers".

Cura

Download from Cura Homepage and skip initial setup.

Save the Hacklab Standard Profile which is managed on github and will be updated as time goes on. Load this configuration file into cura (needs .ini extension, watch out for your browser downloading multiple copies and making them invisible with parenthesis "hacklab_standard.ini (1)")

• Load your stl file.
• Look at the model in cura to see if it's printable
• Turn on support material if you need to
• Click "Slice to GCode" or "Prepare Print" if using 12.10 or newer.
• Or invoke from command line ./cura.sh -i <location of hacklab_standard.ini> -s <your stl name>.stl
• Grab a drink
• Your gcode should now be in the file <your stl name>_export.gcode or <your stl name>.gcode if using 12.10
• Upload and print

Cura Troubleshooting

Arch Linux

• Cura complains of a missing PyOpenGL
  • This is due to a cura packaging error. Change all the references to "python" in the cura.sh file to "python2"

• Gcode slicing always fails
  • This is due to cura coming packaged with an old version of pypy it uses to accelerate skeinforge.
    • Install pypy with pacman.
    • Change the line in Cura/util/sliceRun.py around line 171 from cmd = [<some python variable name>, mainScriptFile... to cmd = ["pypy", mainScriptFile...

Fedora

Tested on Fedora 15 (x86_64 with some i686 packages installed) w/ Cura 12.10

• Packages to satify Dependencies: PyOpenGL wxPython pyserial
• On my system Cura would fail with no explination when generating Gcode. Command Line invokation with LD_LIBRARY_PATH=/lib and a symlinking to libbz2 with the expected version name did the trick. --Scott 18:02, 23 November 2012 (UTC)