Skip to content

Writing post processing scripts

alexrj edited this page Apr 18, 2013 · 3 revisions

This page contains a few hints on how to write post-processing scripts for Slic3r. Post-processing scripts work on the G-code file generated by Slic3r, allowing custom code modifications to be performed automatically as part of the slicing process.

A few example scripts are available under Slic3r/utils/post-processing/ in the Slic3r GIT repository.

Invoking post-processing scripts

Slic3r supports running multiple post-processing scripts on each generated G-code file. Either use the GUI to add the path of each post-processing script, separated by ; or just invoke Slic3r with the --post-process command line parameter:

./slic3r.pl --post-process ~/first-scripts.pl --post-process ~/second-script.sh ...

Each script is called with the full path of the G-code file as the only parameter. Make sure the post-processing scripts are executable or Slic3r will throw an error.

For security reasons you can't supply arguments to the scripts. However, you can just write a wrapper script.

Reading configuration options

All Slic3r configuration options are available as environment variables from within the post-processing scripts, all starting with SLIC3R_.

The following script simply dumps all the Slic3r configuration options to standard output:

#!/bin/sh
echo "Post-processing G-code file: $*"
env | grep ^SLIC3R

In-place G-code modification

Using perl -i it is easy to make a script for modifying the G-code file in-place. Simply iterate through each line of G-code, modify it as needed and print it to standard output:

#!/usr/bin/perl -i                                                     
use strict;
use warnings;

while (<>) {
     # modify $_ here before printing
     print;
}

##Windows Error(s)

If you are getting a can't do inplace edit without backup error when specifying the post-process script, try adding $^I = '.bak'; before the while loop. This will create a backup file of the generated G-Code file. Windows does not like to have two scripts creating and/or accessing a single file at once, so a backup is needed. This is a quick hack that might be obsoleted in future versions.