Post Processors

[GregValiant]

Mark,
I've been hanging around on GitHub, Reddit, and the UM Forum for about three years now. Over that time I've come across ideas for post processors ("Add Cooling Profile" is one) and other scripts that I've found helpful myself.
Since I'm self taught - my coding style is decidedly "non-pythonic", it just works.

The following have been merged into UM Cura for 5.7:
"Add Cooling Profile"
"Display Info on LCD" (this one combines the two existing posts into a single more capable post)
"Alter Zhops" allows the user to kill the zhops over ranges of layers.

"SuptIntMaterialChange" is in the queue at UM. It is similar to Pause at Height but pause for a user to change material for the top layer of a support interface and then pauses again at the end so the user can switch back to the model material. It's terrific for single extruder machines when you have large flat supports. Not so good for horizontal holes and curved surfaces because of all the pauses it can generate.

"Add Cura Settings" was passed on by UM as being too hard to maintain. My Personal feeling was that it's far better than nothing. It creates a list of the relevant settings and adds them to the gcode after the Ending Gcode.

"Little Utilities" is collection of 14 seldom used but occasionally very helpful post processors ranging from "Remove Comments" to "Number the Lines" (some firmware likes to see line numbers).

"Timed Cool Down" keeps the bed and/or build volume hot and slowly drops the temperature-over-time according to the user settings.

"Insert at Layer Change", "Search and Replace", "Time Lapse" were not near as capable as they could be and I've re-written them. In addition to those three I have a re-write of Pause at Height. I obsoleted "By Height" so the new one is "Pause at Layer". No more confusion regarding obtuse settings like "retraction" and "Disarm Time". None of those have been submitted to UM yet.

If you are interested I can piecemeal them out in PR's at a rate of maybe one per week. If you have no interest I will understand that too.

Greg

[smartavionics]

Hi Greg,

I am quite happy to add your scripts as and when you produce versions that are compatible with my Cura variant.

I guess the question is ... is it worth your effort? I have no idea how many people use my builds. May only be a handful.

I tend to make a release every couple of months.

[GregValiant]

There isn't any real effort involved. As I was scribbling them I used your builds as well as UM and Creality to debug. The posts are finished and just sitting here. I use them all the time and I pass them along to other people who may mention somewhere that they have a situation that one of the scripts could fix.

I had put several of them in as PR's on UM (I will probably re-submit them) but things move slowly over there and I'm easily bored. That caused me to keep opening up the files to make minor alterations. I think the constant stream of commits was getting to Remco and Casper.

I've also ported all those post processors to a Visual Basic app. It will accept gcode files from any of the popular slicers. Whether a gcode is created with Cura, Bambu Studio, PrusaSlicer, OrcaSlicer, et al, it can be post processed about 28 different ways. Then it takes and writes the altered code to a new file.

I'm retired, fishing sucks, it isn't like I have a lot of other stuff to do.

[GregValiant]

Here is "Support-Interface Material Change".
The user enters the layers where they would like to change materials. A pause is added at "TYPE:SUPPORT-INTERFACE" and the user changes material. A second pause is added at the next ";" to revert to the model material.
Trying to do a PR between forks was no fun.

This is for single extruder printers although multi-extruders are allowed if only T0 is enabled. It works really well if I do say so myself.
SuptIntMaterialChange.zip
Settings

Code example

[smartavionics]

Hi Greg, I have added it verbatim.

[Sophist-UK]

M600 is a filament change command which is supposed to "move the print head away from the print, eject the filament, wait for new filament to be inserted and the user to confirm, load and prime the filament, and continue with the print." Would this be better than the M0 pause?

The filament change process in Marlin also deals with purging the old filament etc. so it is likely to be a whole lot easier to change filament this way than to have a Pause and then have to do the filament change without the assistance of the firmware.

[smartavionics]

Maybe make use of M600 an option?

[Sophist-UK]

If you have not used the filament change process that Marlin has, and which can be triggered from the hardware menus as well as M600, it is just brilliant!! Way, way, way easier (and quicker) than doing it manually.

[GregValiant]

Hi @smartavionics and @Sophist-UK ,
M600 doesn't work on my older Marlin install and I know from Reddit and reading bug reports that my machine (Ender 3 Pro) isn't the only one. By not enabling the park, unload, load, or purge options in the script then M600 might work as a "custom" command. The way it's written right now, the user would need to include the parameters in the "custom" box. That M600 line would likely cause a conflict with the way the script enters the parameters as separate lines into the gcode. The settings would essentially go in twice. Since M600 doesn't work for me, I can't debug it.

An option from my side would be to take the settings as entered, add them to the M600 line as:
M600 B1 E0 T0 L{load_length} U{unload_length} X{park_x} Y{park_y} Z3"
and alter the custom insertion so it doesn't double-dip on those settings.

If people complain I'll look at it. I've used this script on about 15 prints and I really like it.

[Sophist-UK]

@GregValiant This is why @smartavionics suggested that M600 should be an option in your script rather than a straight swap for M0.

And believe me, it would be worth your while finding a more up to date Marlin build for your Ender 3 Pro than is provided as standard. The speed and quality of my prints is way better with the newer functionality turned on (and dialled in).

[GregValiant]

There must be a purge because we are changing material. Also, since we are changing material the temperatures can be wildly different. I had trouble pulling the PETG out when the temperature would drop to PLA's 200. My fix was to calculate the median temperature and hold at that point for the change. When I continue the print the M109 R holds the machine until the temperature has dropped or risen to the new print temperature. M600 can't do that. It may be a show stopper.

My testing showed that if less than about 60mm is purged, the previous material will not clean out of the nozzle completely. That will allow the previous material to mix with the next material over part of a layer causing a definite weak spot as the layer adhesion will be terrible.
With M600 the user would need to hand purge 60 or 70mm of filament at each pause before continuing the print. With the code that is written, the purge is done with the extruder and is an exact distance.

I'll look at adding M600 and when I get it done I'll pass the script along as you guys will need to debug it.

FYI - I will not be changing my 1.1.5- 8bit mainboard running Marlin 1.1.8 (which prints very, very well thank you) with some unknown new combination. Ain't happenin'.

Rule # 2: "Never upgrade an operating system." Something won't get the memo and things will quickly go into the dumper.

[Sophist-UK]

Your point about temperatures during filament change is very well made. As you point out M600 doesn't do temperature changes - and of course it shouldn't because each G-code is designed to do something very small and specific, and it is intended that users should combine G-codes as needed to get the results that they want. I was only suggesting replacing the head parking, filament moves and pause for an M600, not replacing all the extra G-code that is still needed.

A few more comments:

1. Where possible I think you should try to get variable parameters from the previous G-code rather than have fields to fill in. So for example, existing print temp, retraction distance and speed etc. can almost certainly be determined from previous gcode. IMO it is better generally to avoid options for every minor thing - I would personally try to eliminate trivial options (like whether to issue an M118) and to use either firmware defaults or values from prior Gcode where possible rather than asking the user to fill in a field (providing override values only when absolutely necessary).

2. M600 without parameters uses default filament change parameters defined in the firmware. You should allow these to be used if the fields are left blank as these should already have been tuned for the machine (e.g. the bowden tube length, the unload/load speeds etc.).

3. M127 does a park (to a firmware pre-defined or specified park point) combined with a retract. You might want to consider using this rather than G0 moves as (again) it should already have been tuned for the machine.

4. I assume that there is a reason that the unload and reload are split into 4 G0 moves - is this to avoid the maximum extrusion value set in firmware? (For bowden machines, this should already have been set large enough for unload / load.)

5. I think it is normal to do a standard retract (standard distance and speed) and then a short slow unload before doing a high speed unload. Certainly this is what M600 does.

6. If it were me, to save time I would change temperature at the start of the unload rather than the end, in the knowledge that the temp will not change significantly between the M104 and the filament having unloaded as far as exiting the hotend.

7. I only use PLA so I have no practical experience of changing between wildly different materials, but I would assume that you should probably stick with the median temp for the purge in order that the old material doesn't solidify if the new material is at a much cooler temp (or char if the temp is much higher). As I say, I have no experience whether a median temp is the best approach or whether the purge temp should be explicitly defined as an option.

8. Does this script change filament back again when TYPE changes away from SUPPORT-INTERFACE? Also I am genuinely unclear why you are specifying layers to change at rather than just using the ;TYPE:SUPPORT-INTERFACE line - is this a combination so that you can print part of a layer in one filament and the other part of the same layer in another (as I can imagine that support interface will typically only be part of a layer). But if so, doesn't this mean changing back and forth between filaments twice (or maybe multiples of twice) per layer and if so isn't this a bit of a pain? Anyway, I am trying to imagine how and where filament changes would be required and wondering whether this should be more generalised than just changing at SUPPORT-INTERFACE.

9. Gcode visualisers rely on the ;TYPE: comments to decide how to show the gcode visually, and I am not sure what happens when they encounter ;TYPE:CUSTOM. I assume, however, that you have seen what the results are, so can you confirm that this doesn't cause any issues in cura (or Octoprint) visualisers?

Aside: As for upgrading your Marlin firmware, if you are happy with the functionality and quality of your existing firmware, then it is certainly an option to stick to what you have. (In my case it was 1.1.0RC6 vs 2.1.x - so a lot of bugs fixed and a lot of new functionality.) But then again, you can always try a new version and then revert back to the old one if it isn't as good - if you can find someone else's version to try (or to use the configuration definitions from) then it probably isn't a lot of effort, but if you do have to start from scratch then I would imagine it definitely wouldn't be worth the effort to start from scratch if you are happy with the existing quality.

[GregValiant]

This is from the RepRap Wiki:
M600: Filament change pause
Support Marlin RepRapFirmware Klipper Prusa Buddy Repetier Smoothie Druid MK4duo
.....................Yes..................2.02 and later...........???............Yes1............???.................???...............Yes.............???.............Yes
grbl Sprinter BFB FiveD Machinekit Redeem Teacup Yaskawa MakerBot
???.......No............No.....No..................No........................???............No................No............ ???

So four firmwares support M600 in some fashion. There is no mention of what parameters are enabled so it really becomes firmware version specific.
In the case of my version of Marlin, only M600 L X Y works. None of the other parameters are enabled and the print head does not return to the previous print position. It's pretty useless.

1. The Model Print Temperature comes from Cura. I'll add code to pull the model material from Cura.
   As far as the other settings go, I feel they are necessary. M118 is used by my own "printer server", Pronterface, and Repetier Host along with Klipper and Octoprint. It could simply be added by default, but then people would complain about the "unnecessary line" if they didn't need it.
2. Because of the spotty implementation of M600 across the different firmware flavors, it's just too "iffy". The code (as written) does everything that a fully supported M600 would do. What M600 cannot do is move up an additional amount if the nozzle is too close to the bed. There is a lot of purging and it needs room to collect below the nozzle without getting stuck on the outside of the nozzle. The M600 on your printer might return to the print...where would the purge occur?
   Occasionally there is no retraction before the pause. In that case there cannot be a prime when the print resumes. If there is no retraction before the travel back to the print, there will be a string. I just don't see enough flexibility in M600 to accomplish what I want to do with this script.
3. From what I've read, M127 is used to "close a valve on the hot end" on large bore nozzles. I see nothing about parking. Once again it is very firmware specific.
4. Yes, firmwares may have a limit on what is considered to be an overly long extrusion. Breaking it into chunks gets around that.
5. It is what your M600 does. That is not necessarily true of everyone's implementation of M600.
6. When the temperature change occurs would be dependent on whether or not the user chooses to use the extruder to unload. If they choose to manually unload and are away from the machine for a bit, they could cook the PLA at PETG temperature, or cool the PETG so it would be hard to remove (and possibly break off near the nozzle) at the PLA temperature. Not good.
7. The "median" temperature works well. It is low enough to not cook PLA and hot enough to keep PETG soft. There had to be a compromise there.
   8, Does this script change filament back again when TYPE changes away from SUPPORT-INTERFACE? Yes. Another pause is inserted at the first line that starts with a semi-colon and the user changes back to the model material.
   Also I am genuinely unclear why you are specifying layers to change at rather than just using the ;TYPE:SUPPORT-INTERFACE line -
   In the case of features that require support-interface on multiple layers, it would be a huge PITA to pause for all of them. Yes, Interface (for the most part) only exists on part of a layer, but all the interfaces on that layer print together.
   "...doesn't this mean changing back and forth between filaments twice (or maybe multiples of twice) per layer..." There will be two pauses per layer. One to change to the interface material, and a second to change back to the model material.
   "...and if so isn't this a bit of a pain?" Too many pauses can make it really annoying.
   "Anyway, I am trying to imagine how and where filament changes would be required and wondering whether this should be more generalised than just changing at SUPPORT-INTERFACE" The intent is for a single extruder machine to be able to print an interface that will easily break free from the print. In addition, since the Z gap can (should) be 0.0, the finish is really good compared to having to remove the support from a model.
8. TYPE:CUSTOM is used when a post-processor (like PauseAtHeight) adds a code section to the Gcode. It appeared to be normal Cura usage so I stuck with it.

On a print like this, being able to use an alternate material for support is a large advantage. It is a lid for a PCB box. The feature sticking up on the top is for a DPDT switch.

This is the best orientation for this model. The Support-Interface is 0.6 thick but only the top layers will be an alternate material (PETG in this case). There are 4 pauses. 2 occur at layer 10 and 2 occur at layer 90.

The finish is about a hundred times better than if the two materials were the same. The support comes right off without any scarring and without stabbing myself with the hobby knife.
This was with "M0" as the pause command. The support generally comes off in one piece.

And the support side finish is as good as you would likely get with a dual extruder printer and PVA.

What it isn't good for is horizontal holes. In this model there are 18 layers with Support-Interface on the bottom of the hole and 18 layers with Support-Interface at the top of the hold. That would be 72 pauses if all those layers were included. That would drive anyone nuts (although for me it's more of a short putt than a drive). So yes, this is pretty much limited to specific models with largish flats that need to be supported. But for those specific models it's really good. For a statuette character or a Mandalorian helmet?...not so much.

[GregValiant]

@smartavionics
This file has the code added to change the material box. Unfortunately there is no way to update it to whatever Cura has in the main settings. If a user changes material the script setting does not update. That would require a plugin rather than a post-processor.
There is also a bug fix in this one. (If a retract speed was a float instead of an integer it didn't get concatenated correctly).
SuptIntMaterialChange(2).zip

[smartavionics]

OK, thanks.

[Sophist-UK]

This is from the RepRap Wiki...

So four firmwares support M600 in some fashion. There is no mention of what parameters are enabled so it really becomes firmware version specific. In the case of my version of Marlin, only M600 L X Y works. None of the other parameters are enabled and the print head does not return to the previous print position. It's pretty useless.

@GregValiant You seem determined to look for excuses. We have already determined that even though e.g. Marlin currently supports M600, there are many people whose firmware either is too old for this functionality or it was not enabled in the build - and so consequently the use of M600 needs to be optional. Thus it matters not if only some firmware supports it.

What matters more is what the parameters are, and as you clearly state the use of no parameters is supported by various versions of firmware.

1. The Model Print Temperature comes from Cura. I'll add code to pull the model material from Cura.

You need to make a thoughtful choice between reading the default temperature using an API call and using the actual print temperature as used in the last M104/M109 gcode (because there may be other temp overrides from (e.g. support blocker settings or bridging etc.)

As far as the other settings go, I feel they are necessary. M118 is used by my own "printer server", Pronterface, and Repetier Host along with Klipper and Octoprint. It could simply be added by default, but then people would complain about the "unnecessary line" if they didn't need it.

This is a minor point and I am not going to argue it further. You are the author and it is your choice.

2. Because of the spotty implementation of M600 across the different firmware flavors, it's just too "iffy". The code (as written) does everything that a fully supported M600 would do. What M600 cannot do is move up an additional amount if the nozzle is too close to the bed. There is a lot of purging and it needs room to collect below the nozzle without getting stuck on the outside of the nozzle. The M600 on your printer might return to the print...where would the purge occur?

There is a lot of sense in what you say about the use of basic G-code supported by all flavours as it will result in consistently correct operation.

M600 on my printer moves to the parking position (default is defined by firmware) unloads the filament and waits, then loads new filament when prompted by the user and does a purge - then asks if the user wants more purge or to continue, and only on continue does it move back to the print position. If you have a filament runout detector, it does this automatically when the spool runs out.

But I accept that this may not be how firmware other than Marlin may work, or how earlier versions of Marlin might work and it will definitely depend on the configuration settings used when your firmware was built (which may not have been fully configured or tuned for your hardware).

Occasionally there is no retraction before the pause. In that case there cannot be a prime when the print resumes. If there is no retraction before the travel back to the print, there will be a string. I just don't see enough flexibility in M600 to accomplish what I want to do with this script.

See above - I agree that there is a lot of consistency to be gained by hand coding the gcode rather than using e.g. M600.

What M600 gives those people whose firmware is both modern and well configured is a process which can be more interactive than a manual gcode process can ever be e.g. by asking whether you want to purge more filament. As an example of this, the filament load length assumes that the gripper grips the filament from the very start - supposing it doesn't grip the filament until 100mm of filament should already have been drawn in - the prime is going to be 100mm short. M600 allows the user to fix this - a predefined gcode doesn't.

So, pros and cons on both sides - hence why offering M600 as an option is a good thing IMO.

3. From what I've read, M127 is used to "close a valve on the hot end" on large bore nozzles. I see nothing about parking. Once again it is very firmware specific.

Typo - should have said M125.

4. Yes, firmwares may have a limit on what is considered to be an overly long extrusion. Breaking it into chunks gets around that.

It says in the Marlin firmware: "For Bowden Extruders make this [EXTRUDE_MAXLENGTH] large enough to allow load/unload." If the builder gets it right for your machine, this should have a maximum length which is just > than the bowden tube length. In my firmware I set EXTRUDE_MAXLENGTH to FILAMENT_CHANGE_UNLOAD_LENGTH (because the LOAD length is actually split into fast and slow portions - slow to grip the filament, fast to load it, then slower to purge).

5. It is what your M600 does. That is not necessarily true of everyone's implementation of M600.

That was not my point - my point was not to slavishly follow what my M600 does (and what I gave you was a simplified version) but that a normal retract (at a fast speed) may be needed to reduce the residue of old filament left in the hotend that then needs to be purged.

6. When the temperature change occurs would be dependent on whether or not the user chooses to use the extruder to unload. If they choose to manually unload and are away from the machine for a bit, they could cook the PLA at PETG temperature, or cool the PETG so it would be hard to remove (and possibly break off near the nozzle) at the PLA temperature. Not good.

Well - this is an argument to:

1. Automatically withdraw the filament rather than allowing the user to do it manually, and then
2. Cool the hotend to a maintenance temperature (or indeed all the way to zero) so that it won't cook any remaining material in the hotend if there is a delay, and then
3. Heat it again before the purge i.e. you start the reheat, load the filament to just before the hotend, then wait for the median temp to be reached before finishing the load and purge.

You can do all of this if you use M0 or alternatively M702 and then M701 rather than M600. (M701 is the clever bit that queries for more purge.)

7. The "median" temperature works well. It is low enough to not cook PLA and hot enough to keep PETG soft. There had to be a compromise there.

Oh I agree - when purging you have to try not to cook either the old or new temps and a median is a good guess (in the absence of an explicit temp set by the user). You just don't want to set that until the user loads the new filament - in the interim you want to cool the hotend using M104 S0 and not waiting and then when the user says to load the filament you set M104 Smedian-temp, load the filament close to the hotend, then M109 Rmedian-temp then load the rest of the way and do a purge.

8, Does this script change filament back again when TYPE changes away from SUPPORT-INTERFACE? Yes. Another pause is inserted at the first line that starts with a semi-colon and the user changes back to the model material.

I am not sure that you should be looking for any comment - but rather another ;TYPE: comment. If you have several objects, Cura can insert ;MESH comments for example which should IMO NOT prompt the change of filament back again. You shouldn't get two ;TYPE:SUPPORT-INTERFACE comments in a row without a different TYPE in between, but you can never be certain, so you should probably check that the type is not SUPPORT-INTERFACE.

The intent is for a single extruder machine to be able to print an interface that will easily break free from the print. In addition, since the Z gap can (should) be 0.0, the finish is really good compared to having to remove the support from a model.

Yes - I get this - I am struggling to get supports which break free easily without leaving a small z-gap (which then reduces the quality) - and I can see how use of a different plastic (which doesn't stick to the normal plastic) would improve things a lot. Presumably you only need to do this on the last layer or two of the support, so it is not every layer than contains any support (hence the need to specify layers).

8. TYPE:CUSTOM is used when a post-processor (like PauseAtHeight) adds a code section to the Gcode. It appeared to be normal Cura usage so I stuck with it.

Obviously the gcode visualiser will probably not show CUSTOM using the SUPPORT colour - hopefully CUSTOM has its own colour rather than showing as something else. I think distinguishing it from the standard SUPPORT colour is probably the right thing to do. (In your pictures, I can't zoom in to see the last layer of the support, bet the rest of the layers are bright blue helpers.

I will look at the pics etc now as I am interested to know whether this technique can help me with the quality of my prints.

[Sophist-UK]

It is difficult to zoom in (because it is an inline picture rather than a separate image file), but the surface quality of the inside bottom face looks extremely good considering it was supported. This looks like an excellent technique.

Changing filament just 4 times to get this major boost to quality seems like a good compromise to me.

What it isn't good for is horizontal holes. In this model there are 18 layers with Support-Interface on the bottom of the hole and 18 layers with Support-Interface at the top of the hold. That would be 72 pauses if all those layers were included. That would drive anyone nuts (although for me it's more of a short putt than a drive). So yes, this is pretty much limited to specific models with largish flats that need to be supported. But for those specific models it's really good. For a statuette character or a Mandalorian helmet?...not so much.

Most descriptions of dual extruder printers are for multi-colour, but I actually think that this use case is at least as useful if not more so.

[Sophist-UK]

As an aside, whilst researching PostProcessor scripts I came across this: AddFilamentChangeBeforeAndAfterSupportInterface.py

[GregValiant]

That one will add 2 pauses at every occurrence of Support-Interface in the file. I chose to allow the user to name which layers to include rather than always being all of them. I have found that only the top interface layer needs to be a different material.

Using that other post processor would result in this model having 170 pauses to change filament. Using my script I would only involve the top interface of the two large flat surfaces so there would be 4 filament changes.