What is SMuFF-PP?

A GCode Post-Processor für multi material printing

To overcome some of the quirks and issues I've explained in detail here, I wrote a simple app as an addition for the SMuFF in conjunction with the Filament-Cutter, called SMuFF-PP, which can be found on my Github repository.

This app is a post processor, which means: It reads, parses and modifies GCode that has been generated by your favorite slicer in order to achieve better results on this behave.

Let's analyze the major problem first: Using a Filament-Cutter does deliver better results on multi material prints, because it eliminates possible jams and thus aborted prints or ruined models. However, when one uses the Filament-Cutter, the filament doesn't get pulled completely out of the hotend on a tool change and a certain amount of filament remains in the hotend, which needs to be removed from the hotend (purged out the one or the other way), before the print can continue. 

To get a better visualization, let's see how this looks like on a classic Ender-3 hotend in the picture on the left. As you can clearly see, the Filament-Cutter sits above the hotend and thus, a piece of around 59 mm of red filament is stuck in there, which, if not purged out somehow, will interfere with the printed model. 

Whatever method is being used to get rid of the red residue, it'll waste 59mm of filament on every tool change, which is not the best option.

What SMuFF-PP is supposed to do in order to compensate for this waste, is to relocate the tool change initiated by the slicer to an earlier position, as shown here.

This relocation takes place 59 mm ahead of the "original" tool change (because that's the amount that remains in the hotend) and hence, there's no more "old" filament remaining in the hotend as the "real" tool change takes place.

To achieve this, there needs to be enough filament (around 59 mm in this case) between two tool changes, which is usually not a problem on "bigger" models but may run into issues on smaller ones.

In case SMuFF-PP can't relocate the tool change because there's not enough filament available, it has two options:

All of the aforementioned parameters can be configured in either the settings.xml of SMuFF-PP or (some) via command line. For example, the -t=nnn command line option (Threshold in settings.xml) defines the relocation length, -skip=nnn (SkipThreshold in settings.xml) the minimum extrusion amount that is allowed to be skipped.

The code for purging is a bit too complex for the command line, thus it can only be configured in the settings.xml file. Here's an example on how this looks like:

   <PurgeCode>

        <![CDATA[; SMuFF_PP: Purge start

M83             ; set extruder to relative mode (important!)

G1 E{0:N4} F340 ; Purge out old filament

M400            ; wait for move to finish

G4 P2500        ; wait for nozzle oozing out a bit

M82             ; set extruder back to absolute mode

; SMuFF_PP: Purge end]]>

  </PurgeCode>

Everything between <![CDATA[ and ]]> is supposed to be pure GCode that the printer firmware can understand and handle. Since it is "only" GCode, it can be configured to exactly match the configuration/environment of the printer, i.e. moving the axes to a given position before the purge takes place.

On a Marlin 3D printer one can replace the GCode shown above with a GCode macro, like M819, and put all the purging code in that macro. On a RRF machine, this can be replaced by a M98 macro call, i.e. M98 P"Purge.g". In both cases the purge code is easily editable on the machine itself, in case it needs tweaking, and the post processing doesn't have to be repeated.

As SMuFF-PP has  finished processing a GCode file, it'll spit out some statistics on the modifications made, for example:

----------------------------------------------------------------------------------------------
Statistics: 60 tool change(s); 0 skipped; 60 relocation(s) accomplished; 0 purge(s) needed.
----------------------------------------------------------------------------------------------

The parameters used in post processing, as well as the final statistics are being added to the generated output file, which gets copied and will carry the addition _(SMuFF) in the filename.

 As mentioned earlier, SMuFF-PP is able to relocate most (if not all) tool changes on larger models, which highly depends on the hotend in charge. The longer the distance between Filament-Cutter and nozzle, the less the chance of being successful.

Do I still need a Purge-/Prime Tower?

Yes, you do. There are a couple reasons for this:

Although reason 1 & 2 can be easily compensated by using an Ooze shield in your slicer, the "Color bleeding" can't be fixed this way.

But whatever you do, you'll never be able to get a nice, clean and sharp color transition between two filament colors when using a single nozzle system, especially if the transition goes from dark to light colors or vice versa.

However, since there's no (59mm) residue in the hotend, you'll be able to reduce the size of the Purge-/Prime Tower (and thus the waste) drastically.

To proof this statement, I've sliced, post processed and printed a random model on my Ender-3 (I don't know who this guy is, but the model had the right volumes and dimensions for the test ;o)).

As you can see, the Purge-/Prime Tower is minimal compared to the one in the original model on the right.

This model was created by Dominik Cisar and can be found on Printables.com.

As you might be able to spot, some of the color transitions in my print didn't come out perfect. It still needs some tweaking/tuning.  

If you want to try it out yourself, here are the parameters I used for the Purge-/Prime Tower in PrusaSlicer 2.5 (make sure you go for the "Advanced settings" because not all color transitions need the same amount):

If you compare these purge settings to the ones mentioned here, you'll clearly spot a huge difference. Although it is a different model, the colors are pretty similar. 

All other slicer settings are pretty standard, except, I'd recommend using firmware retractions rather than the retraction settings from the slicer (even though that might mean you need to flash your printers firmware). 

What are the next steps?

My next steps are testing a few different models and see how this works out.
Then there's also this thought captured in my brain: Retracting the filament a bit before cutting it, so the amount of the remains in the hotend will be even less.

Although this seems pretty logical and straight forward, it involves risks of jamming the hotend during tool changes. This is why I came up with this chart of probabilities:

Not sure if this chart is realisticly by any means but at least it's something to start with.