Many slicers mark a feature type by a comment like “;TYPE:Perimeter” (Prusa and Orca slicer have them, but both use a bit different names) . My idea is to take this information and change the printing speed based on a specific feature type and not the speed for the whole print. This would be useful if for example you notice, that your supports are likely to fail, if you don’t lower your speed, but the rest of the print is totally fine. I think a macro which replaces these comments in the gcode with M220 commands could do this. Do these kinds of macros already exist or would there a problem with this?
This is a part of every slicer already. It’s under your speeds.
Simplify3D
Prusa Slicer
Orca slicer and Cura call it “Wall” but same thing
Orca Slicer
Cura
Yes i know that. You misunderstood my post.
I meant changing the feedrate of a specific type during the print, because you see that a support structure is printed a bit too fast during a print, but the other parts of the print are fine, which is why in this situation it would make more sense to slow down only the supports speed and not the whole print.
Thank you anyways for your detailed answer for many slicers. If this would have been my question it would have been very helpful.
I’m still lost here I guess, Your extrusion rate is linked to your speed. Are you saying you want to increase your extrusion rate for a support for example?
I guess the part that threw me off was
support structure is printed a bit too fast
But YOU control that? If your supports are printing too fast you just lower the speed in the slicer.
Can you give a specific situation you would use this?
To your bigger question though…
Do these kinds of macros already exist or would there a problem with this?
This kind of thing couldn’t be a macro because it has to do with parsing the GCode in real time. It would have to be implemented in the code, but honestly this all seems like a Slicer issue. How fast to go and how much to extrude based on the different feature types is what the slicer tells Klipper.
Klipper just decodes that into the motion control to make it happen.
1 Like
Sometimes when i print support, i can see that it could fail, because it starts to move to the sides a bit. For this kind of situation it would be nice to slow down the print speed of the supports. If the rest of the print is totally fine i don’t want to slow down the print speed for everything.
I think this could be done with the “rename_existing” method, where you replace
“;TYPE:Perimeter” with M220 S{speed_factor} . Then do this with every kind of type in the gcode, so you have full control over the print speed even during the print (with default 100, so the print speed goes back to normal if a different typr is indicated in the gcode). I just don’t know if the “rename_existing:” method would work, because it’s not a real command like a G command.
You can definetly change what the printer is doing at a certain G command with variables set with a macro, like the Z_hop firmware retraction.
I know it’s best to configure everything inside of the slicer, but sometimes it doesn’t work as planned so it would be nice to be able to make changes during the print if necessary.
Rename existing just renames another existing GCode command.
The issue is, How are you going to trigger a gcode macro when you’re parsing gcode? In other words, How will Klipper know to “Run this gcode when there is a perimeter type of x in the Gcode”?
Someone might surprise me and show me that it’s possible, but I don’t know of any way.
You can definitely make a macro that takes into account Z-Hop, you implement it in your slicer under retractions:
So that when a retraction takes place it calls the Klipper GCode command to do what you wanted.
As far as I know there is no Slicer that has functionality to implement a gcode for when it starts a certain feature type though.
You could technically implement your own with a script to write in a custom Gcode command line after the feature type is found in a Gcode file. But again, This is modifying the gcode output of the Slicer. Klipper just does what the GCode says.
Now we are talking. Orca and prusa slicer add a comment regarding the type of the feature the gcode is about everytime the type changes. I know this for sure, because if have been using these comments in the gcode to adapt the GradientInfill script of CNC-Kitchen, to work with gcode generated by orca and prusa slicer (i also added a maximum volumetric flow rate to the script).
So the open question is can i replace “;TYPE:Perimeter” and any other type with a M220 command with a specific speed factor with the rename existing method.
If not i would be able to write a postprocessing script which would add a custom command, which could be programmend inside of klipper then (this would probably not be worth the effort though, because i’m already using one postprocessing script to optimise my timelapse and it takes a bit of time, since it’s an python script.
This is how it looks in the gcode
which could be programmend inside of klipper then
Why are you adamant it has to be inside Klipper? I can tell you from experience writing a quick script to add a command into your GCode will be about 5 million times easier than modifying Klipper to do it.
So the open question is can i replace “;TYPE:Perimeter” and any other type with a M220 command with a specific speed factor with the rename existing method.
Yes, You’d do literally that in your script
Psudo-Code:
NewGcode = []
For line in File:
NewGcode.Append(line)
If line = ";TYPE:Support":
NewGcode.Append("M220 S50")
If Substring(Line+1,6) = ";TYPE":
NewGcode.Append("M220 S100")
WriteToFile(NewGcode)
Then Klipper will parse it just like any other GCode file, you make your script take command line arguments for the different feature types and your speed override.
That way you get what you want and you don’t have to touch Klipper.
But again, You can also just change the speed for supports, or whatever other feature, in your Slicer. Which is a lot easier.
You miss my point again. I want to be able to change print speed for a specific feature during the print. Similar to turning on and changing settings for Z hop firmware retraction when it’s needed during the print.
Use a macro with variables you set. The setup is still the same.
[gcode_macro FEATURE_SPEED_CHANGE]
gcode:
{% set CHANGE = printer["gcode_macro CHANGE_SPEED"].changespeed %}
{% set SPEED_FACTOR = printer["gcode_macro CHANGE_SPEED"].speed %}
{% if CHANGE %}
M220 S{SPEED_FACTOR}
M117 Setting speed to {SPEED_FACTOR}
{% endif %}
[gcode_macro CHANGE_SPEED]
variable_changespeed: 0
variable_speed: 100
gcode:
{% set change = params.CHANGE_SPEED|default(0)|int %}
{% set newspeed = params.SPEED|default(100)|int %}
SET_GCODE_VARIABLE MACRO=CHANGE_SPEED VARIABLE=changespeed VALUE={change}
SET_GCODE_VARIABLE MACRO=CHANGE_SPEED VARIABLE=speed VALUE={newspeed}
Then use “FEATURE_SPEED_CHANGE” in your script
and during the print you can do
CHANGE_SPEED CHANGE_SPEED=1 SPEED=50
Where change speed is just a flag to indicate you want to change it.
Obviously all that needs testing and you can expand it to different features if you wanted by utilizing flags in different ways.
Hi sorry forgot answer you. I just finished the project.
I got it working with the help of a postprocessing script. The script is very simple and just takes a split second to excetute.
You can check it out here.
It’s a little bit simpler than the macro you gave me as an example, but similar.
Thanks for your help 
2 Likes
You may set it to [SOLVE].
I’ve labeled my last comment as a solution, does this automatically set it to solved? If not where can i do that?
That’s the checkbox for.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.