GCodeClean is now at v1.1.7

GCodeClean goes to v1.1.4

Releases · md8n/GCodeClean (github.com)

This is really a housekeeping release. Setting things up for the actual file splitting - where GCodeClean splits each cutting action into its own self contained GCode file.

Note a very important, sorta breaking change. I finally got around to specifying the CLI executable’s output name as GCC.exe instead of cli.exe which it has been for some time.


For Future Me To Do - A Review

Looking back at this post GCodeClean hits v1.0.1 🎉 - #37 by md8n

  • Upgrading to .net 7 - Done - and now .net 8 is just about to be released …

  • Using Native AOT for compilation of GCodeClean - Could not get this working, I’ll try again once .net 8 is out.

1 Like

Finally!! - Also a Review

From this post GCodeClean hits v1.0.1 🎉


  • File pre-scan - I haven’t been back to this yet - it ended up being less of a priority

New Features

  • Inject blank lines before significant actions - Still to do.
  • File splitting - My current focus.
  • More support for other GCode syntaxes - A BIG piece of work this one, which will require some significant refactoring I suspect, but almost certainly well worth it in the end.
  • Unit conversion - Change from inches to millimeters - still on the back burner
  • Path optimisation - What I’m really interested in getting into - file splitting is needed for this one
  • Path inversion - swap the start and end of a cut - super interesting problem, but parked for now.

Pain Points

  • #1 is definitely the issue that lots of Windows (or Mac) based users have never used command line / terminal based software before. @Orob has conveniently bypassed this for me by adding a call to GCodeClean via WebControl, which he will now have to change, because I’ve changed the cli commands name. But maybe I should still add my own UI?
1 Like

Amazing work!

I think that a UI would be super helpful. Maslow4 incorporates what WebControl does into the firmware so going forward there won’t be a program running on everyone’s computers to be able to integrate GCodeClean into which would make a stand alone UI really useful.

1 Like

cringe, gcc is gnu C compiler on many systems. that can lead to rather
‘interesting’ error messages if the path isn’t correct.

David Lang

1 Like

if you are interested, but I fear it will drain your effort away from the core

David Lang

why not have gcode clean run on the maslow4 to optimize loaded files?

David Lang

It would have to be re-written in JavaScript and the space available on the ESP32 is pretty limited. I’m open to that idea though!

It did start life as a VS Code plugin - and they’re all TypeScript - so … I would consider rewriting it in TypeScript. Don’t worry, you’ll only need TSC or Bun in the build chain to generate the JavaScript.

But first it is file splitting. And that may be advantageous for memory management, because it splits the file into individual cutting actions. Meaning you could load one cutting path at a time.

Would it be possible to fit it into 10k or so of space? The ESP32 is pretty tight.

Edit: The ESP32 has WAY more memory than 10k, but the webserver running on the ESP32 isn’t going to be happy serving a page unless it’s very light weight

And now it is v1.1.5

Reminder to self - always make sure to test the thing does its primary function before cutting a release.

So yeah v1.1.4 wouldn’t actually run a clean because I had structured the ‘commands’ incorrectly. Now fixed.

Also some other code cleanup housekeeping.

And a first pass of ‘split’ actually showing it doing something - but really nothing, it’s just some data that will end up behind the scenes.


… And now it is v1.1.7

This version is mainly about migrating to the latest version of .net - now v8.0 and an LTS release.

So a chance for a little bit of housekeeping, including taking advantage of some new language features in the latest C# 12

Releases · md8n/GCodeClean (github.com)


Thanks a lot for all your efforts! I’ve been recommending GCodeClean in other venues and maybe that’s lead to some more users.

I’ve just upgraded the small scale CNC capabilities here at the southern Mooselake Manor annex, to a 60x60cm machine with a rotary axis (XYZA this time, not just XZA) and will give it a try after wearing down the honeydo list. Wife seems to think that all our lights and electrical outlets should work after the roofers drove a few nails into the wiring, not to mention a Cat 5 hurricane that rolled through here a couple years ago, that lead to loose connections and burned out wiring and other problems. I have no idea why she would think that’s more important than CNC projects, those lights and outlets all work…

1 Like

Something that I’ve yet to explore in the code. Currently ABC should just pass through. But that’s not taking the maths into account of course.

One of the recent (this week) realisations for me is that the approach I took when first writing this for .net 6 (C# 8) is not necessarily the right approach to take now with .net 8 (C# 12) in terms of optimising performance.

Currently GCodeClean works as a kind of a pipeline of many individual steps. But where everything is pulled through the pipe rather than pushed. And its performance (speed and memory) is impacted by whatever the most processing intensive step is, and the cumulative effect of having every step effectively in operation together. I do get a real consistency to the memory and processor load it causes. But it’s not exactly optimal.

1 Like