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.
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
- 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.
- #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?
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.
cringe, gcc is gnu C compiler on many systems. that can lead to rather
‘interesting’ error messages if the path isn’t correct.
if you are interested, but I fear it will drain your effort away from the core
why not have gcode clean run on the maslow4 to optimize loaded files?
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
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…
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.