FR: New parameter on SET_PRINT_STATS for section type (infill, wall, skin, etc)

Features
1

This request is intended to build the ability to recognize what type of feature is being printed into Klipper. Perimeter, skin, infill, etc.

This would enable a number of interesting possibilities. Most immediately it would allow the new Mainsail feature ‘Pause @ layer’ to delay the pause until the infill section is being printed. This would eliminate surface scars and artifacts that are often seen with a pause for a filament change.

Pause always has some small imperfection with flow, due to the retract, de-retract, and some ooze.
If pause comes back to an outer wall you will see a flaw in that spot. If it comes back to infill there will be no flaw.

I have proposed this functionality to the Dev’s at Mainsail as well as Pedrolamas. Pedro seemed to be onboard with incorporating it into his klipper preprocessor. The Devs at Mainsail (I think) also maybe saw that this feature could be beneficial, but felt the biggest hurdle may be the need for the new parameter in Klipper, and the approval on klippers side.

Finally, I don’t think this is the only use for such a parameter. Having Klipper recognize the type of feature it is printing opens up a number of possibilities that I think could potentially be of use.

2

The only stage where it is known what feature something is, is the slicer. After that, it is just gcodes. To find out what printed line is what is, is an unproportional effort.

A possibility would be - AFAIK sometime it’s done - is that the slicer remarks every feature with an appropriate label.

3

Ohh, sorry if its not clear.

Yes, the instruction must come from the slicer. This is already implemented for Cura, and Klipper preprocessor can then pass that gcode instruction to Klipper.

But, Pedro says this new parameter is required.

4

So it is more a thing for the frontend (Mainsail etc).

That one can take care of such labels and insert the pause at the appropriate section.

5

Yes, it requires integration in the frontend. But I spoke with Pedrolamas the developer of klipper preprocessor as well as the Devs at mainsail, and they both suggested this parameter would need to be integrated into klipper as well.

I don’t code, so I don’t know the specifics beyond that.

Here is a link to Pedro’s comment. Possible to add total filament usage to script? · Issue #1 · pedrolamas/klipper-preprocessor · GitHub

Also, beyond that I know Cura does already denote feature type with comments in the gcode. Other slicers would need to also provide that information.

1 Like
6

You could probably implement this feature now without having to make code changes to Klipper. You could have a macro with a variable like “printing_infill” that is set to “False” by default. Then you could devise a gcode post-processing script that locates the beginning and end of each infill block and inserts gcode commands to toggle that variable appropriately. Then you could have a PAUSE_NEXT_INFILL macro that uses delayed_gcode to issue the PAUSE command the next time the “printing_infill” variable is True.

7

Hi Theophile. That sounds Ideal.

I saw on Pedro’s git that you are working on a script with similar intention.

I am not a programer. Do you have any plan to release your script? Perhaps I can test it?

8

I do plan on releasing it, when I feel like it’s not likely to completely mangle your gcode! I’m currently trying to figure out the source of a pretty major bug that sometimes removes large chunks of gcode. I’m not very good with perl and the thing has gotten to the point that it’s confusing me and I’m the one who wrote it! (As a side note, if there are any perl wizards on here who are interested in helping me, let me know!)