Megahurtz

If one is looking for a robust gcode to stl generation (deslicing) tool, there is a slicer called Voxelizer that has this capability. It has been my experience that it works well. More info: https://all3dp.com/2/g-code-to-stl-how-to-convert-g-code-back-to-stl/

Thank you, sirs (gender assumption - forgive if incorrect).

I too like it. I think byte count is likely pretty suboptimal, and, given time that time may be somewhat sloppy, that too is suboptimal now that I know that (time guesstimates being potentially inaccurate). The concept of popping a wipe at some threshold of material extrusion, during travel/infill/internal walls seems to be the best approach. This is exactly what I am interested in - having the option to do multiple wipes per layer, when they are long layers (i.e. first layer with support and adhesion, a bed full of elements, or both). This is a good point. I do think it best to articulate a wipe during (in descending order): 1) travel, 2) infill, 3) an internal wall, avoiding, if at all possible, doing a wipe during 4) an external wall. Given these considerations, does it make sense to try to tackle this approach in a plugin, or via post-processing?

Good day. I find myself wondering if there is a post-processing plugin that can modify g-code in a time-based manner vs. a print progressive manner. Use Case: FDM, forcing an action via g-code modification every xxx seconds vs. adopting an event based triggering i.e. on layer change. Right now I have a post processing task of wiping the printer nozzle at layer change: https://youtu.be/lnH9Nze5cHM?t=43 While this works for many prints, there are cases where having temporal triggers would make more sense - prints that are small in X/Y but tall (think a tower or some such construct), or ones that are very large in X/Y (think having a print bed full of small highly-detailed short parts). In the former, the nozzle gets wiped at every layer and just wastes time however, for the latter, it would nice to be able to force a wipe every xxx seconds (xxx being driven by the material dynamics), to keep excess filament artifacts from getting baked into the printed model. So, does anyone know of such a way in which to modify Cura-generated g-code to have gcode steps every xxx seconds, to facilitate temporal-based actions? TIA. ~MHz

Good day. Dredging up an old thread here... Is a Post Processing Script an appropriate way to have an external binary process a sliced gcode file, before it gets handed off for saving, printing, or sending? There is a new utility binary (ArcWelder: https://github.com/FormerLurker/ArcWelderLib) that takes a .gcode file full of G0/G1 commands and generates G2/G3 LH & RH arc/circle based replacements. This often has the benefit of improving print quality by making a bunch of G0/G1 commands into a single G2/G3 commands which often serves to decrease gcode size for a given model, removes many potentials for printer stalls due to FW buffer dynamics, and potentially shortens print time. One can script it using external tools outside of Cura, of course, but that serves to muck up the workflow. It would be nice to be able to just add a final post processing step and have Cura kickoff the postprocessor (ArcWelder) binary to scan and convert the gcode, prior to the final step of Printing, Saving, Transmitting the slicer generated gcode. Please advise. Thanks.