Feature To Allow New Features

[escfoe2]

Pretty much everyone can agree that we would like to be able to edit gcode on the fly (during the print). Pretty much anyone experienced with programming and actual GCode knows that's extremely difficult, if not impossible.

I have a suggestion that can make it possible.

GCode files support comments and comments are ignored

Here's what I propose:

First, put all of the settings used to Slice the model into maybe JSON format at the top of the file. Next, when slicing, categorize the line for every command that belongs to the perimiters, retractions, interior walls, infill, filament changes, brim, etc, into their own named category Add it, as well as the layer number, as a comment to the end of each line

For example, something like: G1 X81.054 Y147.187 E0.01971 ;{PERIMETER, 1} G1 X81.835 Y146.788 E0.04888 ;{PERIMETER, 1} G1 X82.977 Y146.223 E0.09125 ;{PERIMETER, 1} G1 X85.182 Y145.053 E0.17428 ;{INFILL, 2} G1 X86.248 Y144.444 E0.21511 ;{INFILL, 2}

Now, in a software controlling the 3D printer, such as Octoprint, we can have a plugin that allows us to not only visualize that GCode (already exists), but also select parts of it. Then we can turn off parts of it as well (give sections of certain categories to ignore), and using the settings provided by Cura, we can insert new commands.

This would allows us to, say, stop the printer from trying to print a small piece of support material that previously collapsed. If it sees a category or the x/y/z coordinates are within the bounds of a selected object) it can insert a retract command (using our exact settings from the slicer) and then ignore those gcode commands, move to the next location, insert the un-retract command, and pick up where it left off.

This would be particularly helpful when

• We realize that the part never needed support material. We can just turn off the Support category
• We want to remove infill. Turn off the Infill category
• We have a tiny failed support, select the bounds of that support in the visualization and turn it off.
• Maybe we want to add or remove ZHop to every retraction.
• Maybe we want to turn on or off retraction itself.
• Maybe we forgot to remove the filament change script before slicing. We can disable it during printing before it gets there.

I'm sure there's more use cases, but this is what I could think of that would make it super useful and powerful. It would help the environment by wasting less plastic, and help with the frustration of wasted time stopping and restarting prints.

By all means, if you can think of a better way, please do, but I do believe it starts with the slicer. Any other mechanism in line will need to know how the slicer produced the GCode and WHAT the GCode is doing in order to have any realistic control over its actions.

[Ghostkeeper]

There's a useful format for listing toolpaths that is currently the industry standard: .gcode. Cura does list the layer numbers, and the structure type (walls, infill, skin, etc) it's working on, as well as which mesh it's working on, right in the g-code output of every file.

These features are intended for post-processing, such as Cura's own post-processing scripts feature, but also for OctoPrint and the like, or even the firmware. I know that it has been applied in OctoPrint to be able to delete/cancel printing an object while it's being printed. It's not a use case you've listed, but a common one when printing multiple objects and one of them got loose from the build plate, so that the rest of the objects can still be saved.

So as far as I'm concerned this already exists. It's not in the same format as what you suggest, but with comments to indicate the start of a certain section instead of at every line. Programmatically this is practically the same though (and much more efficient for the file size and processing speed on the printer).

To turn off retractions you'd have to either look at G1 commands with negative E values, or simply use firmware retractions in Cura and then turn off those firmware retractions (i.e. set the firmware retraction distance to 0).

Is there anything you'd want to be able to do that you're not currently able to do with this?