Post processing with Slic3r (Become an expert)

Our models aren't always perfect. Sometimes when we slice a model, there are issues with interpreting its geometry. Sometimes we just want to play around with the G-code to see how it will affect the model and print. That is where post processing comes in.

We can set up Slic3r to automatically run a post-processing script on our sliced model. Post-processing scripts can do things such as removing stray lines from the model to reducing the chance of blobbing on some surfaces; or even calculating the weight of filament that is needed to produce the model and give us the cost for that model in materials.

Getting ready

For this example, we will use one of the scripts put together by the developers of Slic3r to compute the cost of the filament used. The example script is in Euros, and the cost is just an example. To get the cost, we will need to change the units later, calculate the cost of the filament we are actually using, and put it into the script. For now though, we will go with the default script.

Note

For Windows users, the current post-processing scripts are written in Perl. Users will need to install Perl in order to run these post-processing scripts.

How to do it...

1. Get the filament-weight.pl script from the Slic3r GitHub at https://github.com/alexrj/Slic3r/tree/master/utils/post-processing.

2. In the Print Settings tab, select Output options.

3. In the Post-processing scripts section, input the absolute path to the script we are running. For example, on Windows, use C:\Slic3r\scripts\filament-weight.pl.

4. Slice the file. In this case we are using the Snake example again.

5. Once the slicing is finished and if we open the file, we will find the following at the end of the file:

   ; filament used = 681.3mm (4.8cm3 or 6.00g PLA/5.04g ABS)
   ; costs = EUR 0.30 (PLA), EUR 0.10 (ABS)

   This is different from the original G-code file ending of:

   ; filament used = 681.3mm (4.8cm3)

Note

If using a Windows machine gives an error, or the output G-code file does not change when the post-processing script is run, a change has to be made to the post-processing script.

Windows machines have limitations on how many processes can access a file at the same time. To get around this, we can make a backup file of the original and then run our process on the original. To do this we add $^I = '.bak'; before the While loop in the PERL script.

There's more...

A good idea is to keep all of our scripts in one place. A scripts folder inside the Slic3r folder is a good place, or you can place it in our user directory. When updating Slic3r, make sure that we back up the folder before installing the new version.

Each script must be executable by the host system, and must be a script that the host system can run. As noted previously, Perl isn't on Windows by default, so it would need to be installed. However, other scripting languages could be used by Slic3r.

Post processing scripts are passed the full path to the sliced file. Slic3r configuration options are available to post-processing scripts as environment variables that start with SLIC3R_.

Because post-processing scripts are able to call anything they normally could, it is even possible to make calls to a server and pass along data for the server to store or do other things with.

As mentioned in the previous section, the scripts don't have to be all in Perl. It just happens to be the language that the developers prefer, and that Slic3r itself is written in.

For Linux and Mac users, we can use shell scripts to call other programs, or do processing itself.

For Windows users, the basic batch file can be called.

If we need arguments passed to the script, Slic3r cannot do that. We would need to create another script for Slic3r that wraps our original script. That script would then call our original script with the arguments we want.