Saturday, July 6, 2013

Slicing for LinuxCNC

With LinuxCNC running my 3D printer, I have had to tweak my slicing settings to get good results.  I normally use Slic3r, but Johann uses KISSlicer, so I tried both.


If you are printing with LinuxCNC, it is important to note that homing is completely different than with typical Arduino firmware.  This is partly because the Arduino firmware essentially ignored decades of standardized gcode prior art, and partly because controllers like LinuxCNC have multiple coordinate systems (machine, world, part, and joint coordinates, for instance) which are generally all swept into "world" coordinates in most 3D printers.

Anyway, the auto-homing typically inserted at the start of a gcode file generally won't do what you expect, so it is important to make sure you have manually homed the X, Y, and Z axis before your first print, and REHOME THE EXTRUDER AXIS to zero just before printing anything!  If you do not home the extruder axis, the first thing that will happen when you start your print is your extruder will try to 'unwind' all the filament it has extracted and end up ejecting the filament out of the extruder, and you will get to start over again.  I am looking into fixing this with gcode remapping, incremental coordinates, or some other solution, but for now just remember to re-home the A (extruder) axis before each print!


My issues with KISSlicer mostly related to not having any familiarity with it.  I started with Johann's Rostock config from the settings in his Kossel github repo (my printer uses 3mm filament and a 0.5mm nozzle like his Rostock).  These slicing settings were reasonable, but I couldn't get gcode that worked for LinuxCNC (it still used E for the extruder axis instead of A).  Finally, I found the "Axis" pull-down on the Printers -> Extruders tab, which let me set the axis to A.  Using the "5D - Absolute E" firmware type setting, this got the axis setting fixed up.  Temperature was still not working properly.  M1xx parameters in RS274D/ISO 6983 require P and Q parameters, not S as used in Marlin and friends.  This can be fixed in the Ptr G-code tab under Select Extruder.  While there go ahead and fix the Deselect Extruder temperature setting, and add your personal prefix/postfix gcode.


I default to using Slic3r, which has a straight-forward Mach3/EMC gcode flavor setting under the printer settings tab.  Despite having well tuned slic3r settings for this printer when I had it running via Marlin, I was having a terrible time with blobs and ooze.  Nothing I did with the retraction settings or wipe seemed to fix the problem, although dialing up retraction did seem to help a bit.

It turns out the current version of slic3r (0.9.10b) forces a few settings if you select the Mach3/EMC gcode flavor.  Essentially, selecting this gcode flavor forces retraction to be combined with subsequent travel in a g0 move, and disables wipe entirely.  LinuxCNC performs coordinated g0 moves, so if the travel distance was very far, the retraction wasn't happening fast enough to avoid ooze no matter what I set it to.  And wipe wasn't helping because it was being disabled by my selection of the Mach3/EMC gcode flavor.  I made a small patch that fixes this issue and hopefully it will get resolved in a newer version.

Here's a print from slic3r with my 3mm filament/0.5mm nozzle with 0.2mm layers and 0.4mm infill:


  1. 'G92 A0' should suffice to modify the G92 offsets so that the current A coordinate is zero.

  2. Here my custom GCode:
    G92 A0; set extruder axis to 0
    G28 ; home all axes

    M104 S0 ; turn off hotend temperature
    G92 A0; set extruder axis to 0
    G28 X0 Y0; home X and Y axis
    ; M84 ; disable motors does currently not work with EMC
    M2 ; End of program