How to deal with Post-processing script "Retract Continue"

[Supramaker 0]

Hello,

Using PETG, I am trying to eliminate stringing (as probably anyone using this material). I switched on retractions but in my case, when any retraction takes place, a small break occurs, during which material keeps extruding and leaves a blob (I tested many combinations of temperature, retraction length, retraction speed and prime settings).

 

Since any movement stop (or disruption of extrusion) is detrimental to quality, I am trying to use the "Retract Continue" post-processing script. As I understand, there should be no break as the retraction takes place simultaneously with the following travel movements. Is that correct?

 

But I do not exactly understand how this script works (and it is difficult to find a documentation).

 

1) Do I need to enable retractions in the main settings for this script to work?

2) If I enable retractions in the main settings and set a retraction distance there, will the script put additional retractions (proportional to the sum of the lengths of all following consecutive travel movements), or will it ignore the retraction length from the main settings?

3) What is expected if I enable retraction in the main settings with a retraction distance of 0 (zero)?

 

Or you could refer to the documentation if these questions are already answered there.

 

Thanks

Rick

[Slashee_the_Cow 97]

I haven't actually used it (although I probably should) but looking through the code I can be 90% sure of the following:

 

1) Yes. The script checks for retraction moves.

2) The amount it changes is not relative to the retraction settings, it will only adjust the retraction by its own speed setting.

3) The script won't do anything. It only activates itself when it sees retraction (a negative change to the extruder position).

[Supramaker 0]

1 hour ago, Slashee_the_Cow said:

2) The amount it changes is not relative to the retraction settings, it will only adjust the retraction by its own speed setting.

3) The script won't do anything. It only activates itself when it sees retraction (a negative change to the extruder position).

 

Thanks for clarifying so far.

 

Own speed settings? I thought changes would be proportional to the length of the travel.

4) Does the script work in a way to do the retraction with the speed needed to be just finished at the target coordinate of the travel? If not, when is it finished? If there is a de-retraction or priming, how is it timed? This last question is important, since ideally priming should not start after the new extrusion line.

 

5) And how does it behave when the travel path is composed of several movements (because it does not reach the target in a straigt line)? Is the retraction finished after the 1st travel movement or is the retraction fractioned as well?

 

6) I don't know if activating retractions with a length of zero would generate commands with E0 (if relative mode), I am still doing experiments. But anyway, it is still unclear to me if the "travelled" retractions inserted by the script are additional or not (with a retraction set to a non-zero value). I did an experiment: I set retraction of 0.01 just to be sure that the script would be triggered, trying to have mostly "travelled" retractions. As a result, I got small breaks again. This behaviour defeats the purpose of the script I think. The script should be able to execute the whole retraction while moving, so avoiding breaks.

 

7) When the script does its changes, are all other settings concerning retractions (de-retraction for example) still in effect? Does the usual retraction command in the original Cura output "G1 E-x" stay untouched?

 

8 )  How can I identify the retractions introduced by the script? I am now working on that actually, but this is very time consuming. 

 

9) Should I expect g-commands like this (assuming relative extruder mode)?:

G1 X123 Y123 Z123 E-1   ; <== both travel and negative extrusion in just one line

 

10) If I could coalesce the effect of the setting "Z hop on retractions" in the same g-command, it would be perfect. Would it be possible in theory to achieve retraction, z hop and possibly wipe in just one command? The purpose is again to avoid the break caused by the z hop movement: When the bed begins to move down, the nozzle moves away and the filament is pulled back synchronously!

 

If someone would contribute to understanding this script, I would avoid a lot of nasty experimentation work, and others too...

 

So please!

 

I will end up learning python sometime.

 

 

[GregValiant 1,141]

This is another of my re-writes that is waiting in line for approval.

The Retract Continue included with Cura doesn't work if you are using Z-hops.  This one does.  (That was the only change I made.)

RetractContinue.zip

If you intend to use Z-hops you should use the new version.  In Cura use the "Help | Show configuration folder" command.  Within the config folder will be a "scripts" folder.

Unzip the file and copy RetractContinue.py into that "scripts" folder.

Next...

Go to the Cura installation folder and navigate to "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\scripts" and rename the stock RetractContinue.py file to RetractContinue.OBS" so Cura will ignore it.  When you restart Cura the new version will be available.

 

This snippet is a combing move around a circle and is an example of what you will see from the script.  For this example retraction distance was set to 5mm.  The "mm of filament/mm of distance" was 0.05.  That seems to be too much for this particular print

G1 X182.69 Y190.89 E1736.58285 >>>>last extrusion
G0 F7200 X182.595 Y190.86 >>>>>wipe
G1 F2700 E1731.58285 >>>>> retract 5mm (per the retraction setting)
G1 F7200 X182.503 Y191.143 Z7.80 E1731.56797
G1 X184.368 Y191.880 Z7.80 E1731.46770
.....47 more moves all with a bit more retraction
G1 X116.694 Y191.902 Z7.80 E1720.22590
G1 X116.788 Y192.186 Z7.80 E1720.21095 >>> the Retract Continue script adds an additional retraction of 11.37mm
G1 F2700 E1736.58285

 

For that example a setting of .05mm of filament / 1mm of distance is too much.  That would draw molten filament up into the heat break of my printer.  Not good.  Setting it to .025 results in a total retraction of about 10.7mm which might be doable.  I'd probably go with 0.015 which results in a total retraction of 8.5mm.  Definitely much better for my printer.

I print a lot of PETG and I've settled on 235° which seems to be a decent balance between the stringing problem and good layer adhesion.

Edited November 15 by GregValiant

[Supramaker 0]

6 minutes ago, GregValiant said:

If you intend to use Z-hops you should use the new version. 

Thanks a lot!

I could follow your example very well.

In my experiments, I had 0.1 set. My printer survived 😀 I did that because almost no retraction was set from the settings.

 

OK, I see I am more on track now.

So the retraction setting itself remains unchanged and new retraction is added by the script along the travels.

This script works as retraction should have always worked.

Can I infer that priming is forced to begin just at the start of the new path?

 

"G1 F2700 E1736.58285"   <== priming

Now we need a post-processing script to spread priming over the next starting extrusion path. No script available for that?

Perhaps I should really learn python, I have a book already in the shelf just waiting... Or Cura will generate better gcode in the future that does not need to be "patched"?

 

Thanks again!

 

[GregValiant 1,141]

No matter what someone asks to be included in the Cura gcode - someone else will ask to remove it.  There will always be room for post-processing.

A fella that posted here built a very large printer and the way it was configured there could be no retractions.  Oozing while traveling dropped the pressure in the very large heating chamber enough that the next extrusion always started out dry.  I wrote a script for him that does kind of what you are asking for...it continued a slow extrusion throughout travel moves and oozed on purpose.  That allowed the printer to start the next extrusions with plastic actually coming out of the nozzle.  He didn't care about cleaning up the strings.  (That particular script is his property.)

 

Perusing other scripts is how I learned what little I know.  The scripts I've altered I did for myself.  I just figured I'd pass them along in case anyone else was interested.

 

"Can I infer that priming is forced to begin just at the start of the new path?"

Yes.  It is always:  1) Prime 2) Do an extrusion".

G0 F7200 X116.392 Y191.152 >>>last travel move
G1 F2700 E1761.20839 >>>Prime
G1 F7200 X116.466 Y191.443 Z7.80 E1761.20389 >>> 1st extrusion

 

"... spread priming over the next starting extrusion path".

I dunno.  It's what it already does since it is extruding at that point.  You can try using the "Extra Prime after Retract" setting in Cura if you need to have more material available for the start.  It can cause blobs as the mm³ is always the same regardless of the length of the travel move.

 

Edited November 15 by GregValiant

[Supramaker 0]

3 minutes ago, GregValiant said:

It can cause blobs as the mm³ is always the same regardless of the length of the travel move.

Exactly the same applies to priming. I mean when priming takes place, the pressure will not rise suddenly, assuming the speed fits. But for different lengths it will not fit, that is the point. If it does not fit, you get a blob (too fast) or a gap (too slow). Extra priming would not be needed if the speed is tuned depending on the length of the next extrusion path (I think).

 

I am actually engaged in tuning coasting - same issue. It happened that I printed a piece similar to a conus, going narrower upwards. The coasting setting was appropriate at the bottom part of the piece, but I got huge gaps at the top. Again, the coasting amount not depending on the length of the extrusion path is bad. 

 

I marked your reply as a solution.

 

[GregValiant 1,141]

Settings like Pressure Advance and Linear Acceleration need to be supported in the firmware.  There is only so much you can do in the gcode before you start to hamper it.  

[Supramaker 0]

Wait - you mean that if my board supports Pressure Advance and Linear Acceleration and these features are activated in its firmware, then Cura would automagically generate a better gcode? 

 

Or do you mean that the same gcode would be executed better by the board? 

 

(Now urgenly checking the Duet 2 WiFi running the last RRF firmware version...) 

[Supramaker 0]

OK, I  will calibrate the Pressure Advance of my board. 

 

Don't know if what Cura does to emulate Pressure Advance must be switched off or changed, because then I would have two solutions for the same problem working in parallel - not good. 

 

For some reason I was thinking that Pressure Advance was possible with Klipper only - sorry, still learning. 

[GregValiant 1,141]

Some things can be passed along in the gcode.  Others need to be supported by the printer firmware and must be set up in the printer.  There may be pressure advance Gcode commands (mostly likely Mcodes) that would need to be added to the gcode.  That can be very printer specific and is different from manufacturer to manufacturer and likely from firmware developer to firmware developer.

Raise3D used M1001.  My Ender doesn't support pressure advance and would ignore M1001 as being an illegal command.  A TronXY might be configured for M650 but the owner changed the firmware to JYers and now it's something else.  Your Duet might have a completely different way to configure it.

At some point you run into the fact that UltiMaker does the heavy lifting on Cura.  If their printers use pressure advance they will pay their people to write it into Cura.  If not then you are stuck putting the commands into the StartUp gcode or using a post processor like Insert at Layer Change to sprinkle commands into the gcode.

 

[Supramaker 0]

I won't be embarking in configuring Pressure Advance right now, but that is high in my priority list. One issue at a time. But yes, Duet 2 WiFi supports Pressure Advance. For Pressure Advance, I think will have to look at following Cura settings:

 

"Coasting",

" Flow rate compensation Factor",

"Gradual flow enabled",

"Gradual Flow max acceleration",

"Reset flow duration"

"Flow equalization ratio"

 

not to speak about retraction, combing, coasting and z-hop (anything that changes speed or flow). Lot of things to be revised. Fell free to complete the list.

 

Coming back to Retract Continue, I took a quick look at the changes made by the script.

Just sliced a tower with/without Retract Continue (0.05) and compared the results. I found following unexpected results:

 

RC changes travel moves INCREASING extrusion (not retracting), while originally no priming but a retraction was taking place:
Line 3408 / 3416 

 

RC changes travel moves decreasing extrusions at first, then increasing them again:
Line 3462 / 3470

 

Right now, I don't feel comfortable using this script. When combining it with other scripts, I am afraid that strange things might happen.

 

(if you are interested, find the project file attached, created without RC).

 

BLVMGNC300-RetractTower-4Forum.3mf

[GregValiant 1,141]

That project file doesn't have any post processors active and the travel speed of 1000 is throwing a "can't slice" error.

Within those snippets above; the retraction distance is 4.4656 and the print speed is 1000mm/sec.

That's either a very capable printer or something is wonky.

Post processors run in the order they are listed.  You may be getting an interference if one must run before the other.  There are also cases where one post is not compatible with another because of the changes it makes in the gcode.

 

[Supramaker 0]

Thanks for your interest.

 

Apparently, the speed limits in your printer configuration are set too low. I know that because I used a copied printer profile at first, when I used this printer for the first time, I got similar error messages.

 

Yes, I have a quite capable selft-made CoreXY printer, but it is not unique (there is a build template), other users set even higher speeds... but mine is just about 10 days old, so I am conservative 🙂

 

The intention of the fast travels is to diminisch stringing.

 

I will re-generate the gcode files using lower speeds and export the project files again (I was assuming that you would like to generate the post-processed instance yourself).

 

I understand that without detailed examination no comment can be made on the peculiar behaviour of the script.

 

That will take some time though.

 

[Supramaker 0]

Here I am again.

I recollected both cases. This time the settings are more reasonable. The model has per-model settings making it slim (facilitates recognizing problems and saves material and time).

 

Left side is without post-processing (BLVMGNC300-RetractTower_No-RetrCont4Forum.gcode)

right side is with post-processing (BLVMGNC300-RetractTower_RetrCont4Forum.gcode)

 

RC does not retract during travel moves, but extrudes after a retraction instead:

 

Line 3237

 

Line 3315

 

RC „modulates“ its retraction in a strange way:

Line 5498

 

Line 5543

 

Not that bad, but I do not quite understand. 

 

You mentioned a high retraction distance from my previous post. In the meantime I determined that up to 1.8 mm retraction distance, the print is perfect but stringing is massive. It can only be completely reduced beginning at over 2.4 mm. Unfortunately, gaps begin to appear already at 1.2 mm. At 1.6 the gaps grow several mm wide. The lines following retraction are started underextruded. Even huge values of extra prime did not help, but ruined the print completely instead. Why, is unclear to me. Extra prime should help in this case. No setting yields an acceptable compromise.

 

Which death should I die?

 

RetractionContinue did not help either. Not surprisingly, this is more a de-retraction issue.

 

So I searched and found a post-processing plugin called "ScalableExtraPrime":

https://github.com/Pheneeny/CuraPlugin-ScalableExtraPrime

and there is a similar request in the Cura github:

"Retract extra prime amount calculated according to travel distance #3658"

https://github.com/Ultimaker/Cura/issues/3658

 

The script is old but should work, supposedly. It is a pity that I cannot load it, the log says:

 

 ImportError: cannot import name 'ScalableExtraPrimeAdjuster'... 

 

(that's another script in the package).

Looks like a trivial error to me, not imported/declared correctly.

 

That was my second-to-last hope, before I engage tuning Pressure Advance.

But wait, there are still some Cura parameters addressing anticipatory pressure changes, similar to Pressure Advance. I will try that tomorrow.

 

Actually, the printer should print the rest of it self, some non-essential parts are still missing, which should look good 🙂

That is why I am trying so hard, but it is a chanllenge, believe me.

 

Have a nice day.

 

 

 

BLVMGNC300-RetractTower_RetrCont4Forum.gcode BLVMGNC300-RetractTower_No-RetrCont4Forum.gcode

[Slashee_the_Cow 97]

50 minutes ago, Supramaker said:

The script is old but should work, supposedly. It is a pity that I cannot load it, the log says:

 

 ImportError: cannot import name 'ScalableExtraPrimeAdjuster'... 

 

(that's another script in the package).

Looks like a trivial error to me, not imported/declared correctly.

There should be more information in Cura's log file than that. Just open the configuration folder (in Cura, go to Help > Show Configuration Folder) and look in cura.log. Probably just search for the name "ScalableExtraPrime". The lines around it will probably be relevant too.

[Supramaker 0]

The  file/script/module "ScalableExtraPrimeAdjuster" cannot be imported from the main code "ScalableExtraPrime" (it has "no attribute", something ridiculous trivial):

 

 File "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py", line 207, in loadScripts
     spec.loader.exec_module(loaded_script)  # type: ignore
   File "<frozen importlib._bootstrap_external>", line 883, in exec_module
   File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
   File "C:\Users\rcast\AppData\Roaming\cura\5.5\scripts\ScalableExtraPrime.py", line 14, in <module>
     from . import ScalableExtraPrimeAdjuster
ImportError: cannot import name 'ScalableExtraPrimeAdjuster' from 'PostProcessingPlugin.PostProcessingPlugin' (C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py)
Exception: Exception occurred while loading post processing plugin: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster'
 Traceback (most recent call last):
   File "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\PostProcessingPlugin.py", line 210, in loadScripts
     loaded_class = getattr(loaded_script, script_name)
AttributeError: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster'

 

The same happens with "ScalableExtraPrimeAdjusterTest".

 

I cannot dial with that issue now, it would push me back (since I am not acquainted with python) and I must  get the printer to work at least at an acceptable quality level. But I will sure try, weeks later I assume.

[Slashee_the_Cow 97]

Post the scripts here (or point me in the direction to find them) and I'll see if there's a quick fix, assuming @GregValiant doesn't beat me to it.

[Supramaker 0]

9 hours ago, Supramaker said:

So I searched and found a post-processing plugin called "ScalableExtraPrime":

https://github.com/Pheneeny/CuraPlugin-ScalableExtraPrime

and there is a similar request in the Cura github:

"Retract extra prime amount calculated according to travel distance #3658"

https://github.com/Ultimaker/Cura/issues/3658

 

I could manage to load the main script "ScalableExtraPrime" (was wrong api version in the json-file) and I get the setting options in the settings panel, although I still see the same errors about "ScalableExtraPrimeAdjuster", which is definitely called from the main script.

So I don't dare to use it, as I could suddenly extrude the whole filament role at once 🙂

 

Please see the link, your help is very much welcomed.

 

 

[Supramaker 0]

 

In case you are looking for the settings for this plugin, they appear in the Material-Section, not in the the Travel-Section as I would have expected:

 

 

 

As I said, not trustworthy, since the subroutine "ScalableExtraPrimeAdjuster" would most probably not work, it could not be loaded:

 

 Exception: Exception occurred while loading post processing plugin: module 'PostProcessingPlugin.PostProcessingPlugin.ScalableExtraPrimeAdjuster' has no attribute 'ScalableExtraPrimeAdjuster'

 

Same for "ScalableExtraPrimeAdjusterTest", although I don't see where it is used.

 

Hope this helps.

 

[Supramaker 0]

And according to the logs, "ScalableExtraPrime" is recognized as a plugin, while the other two "ScalableExtraPrimeAdjuster" and ScalableExtraPrimeAdjusterTest" are seen as scripts.

[Slashee_the_Cow 97]

"ScalableExtraPrimeAdjuster" and "ScalableExtraPrimeAdjusterTest" aren't post-processing scripts - they're part of the main plugin and go in the same folder as that.

[Supramaker 0]

I did dare to run the script (stood right beside the printer to switch it off in case of emergency), but after printing a piece exactly the same as before, I see no changes. The piece still shows gaps with the same size at a retraction distance of 1.2 and above, and a lot of stringing. It is doing nothing without the two other scripts I guess. I still need to l thoroughly do the math with the numbers in the Gcode file to confirm that.

 

I would very much appreciate if anyone would try to fix the installation of this plugin.

[GregValiant 1,141]

The plugin was put together in 2018.  On August 25, 2023 the author added a note to the ReadMe.md file.

"This plugin is no longer being developed or updated and should not be used.".

The note appears to have been added after the author made an attempt to get the plugin to work with Relative Extrusion.  At that point it appears that the towel came flying into the ring.

You can leave a note on the GitHub page.  Maybe showing some interest will get Pheneeny to think about it some more.

[Slashee_the_Cow 97]

9 hours ago, Supramaker said:

I would very much appreciate if anyone would try to fix the installation of this plugin.

 

 

 

 

 

 

 

👍