There’s a self-contained 64bit Release build for Linux, Windows and OSX, you can get the relevant one from https://github.com/md8n/GCodeClean/releases (open up Assets within the latest version )
But you can also build it yourself (e.g. for other chipsets like ARM, 32bit, specific Linux flavours, etc.).
This does require the .net Core 3.1 SDK - but that runs on anything (Linux, OSX, Windows) and hopefully I’ve included enough instructions for anyone familiar with a command prompt / shell to be able to build it.
I had a 14.7MB .nc file (output from estlcam) that I was able to ‘clean’ down to an 8.92MB file with a tolerance of < 0.001mm on all commands.
Please note that it’s still a “work in progress” as I add support for more of gcode spec (yep there is actually a spec). But what’s there already seems to work well for many gcode files.
Two things are particularly useful for ‘explaining’ gcode:
An optional --annotate flag, where it will add inline comments describing what each line does.
A per line linter, where lines with multiple commands (G, M, F, S, T) are split up onto individual lines in the order that they should be processed (according to the specification).
If you’re willing to share he file. Then I’d be happy to use it for testing.
Alternatively, if you get a text editor (such as VS Code, which also runs on anything), then you can try debugging it for yourself. I’d be happy to accept pull requests on that code.
Share via dropbox, or something similar if you prefer.
OK - I’ve done a little fix and pushed that up to GitHub.
See how it works out for you now.
The big change you should see is it clipping the number of decimal places.
But it does manage to drop a few of the linear movements.
I’d like to jump in on the beta testing here as well, I have a few gcode files I would share also. I create my objects in Easel and let it provide the gcode. This seems to work pretty well as far as the results go, but I see it do some really strange stuff also. The file I will share cuts exactly what I want, but in one small section it makes the same cut 6 or 8 times, and each time it lifts, moves back to the start of the line, and then plunges and cuts it again (the rest of the rectangle is cut as you would expect). I wonder if your tool will remove that bit of inefficiency? Regardless, I’m all in for trying and testing and helping where I can.
I have 2 files to share, both were generated using Fusion360.
This first one causes issues; the machine slows down to a crawls in the curved portions. hook.nc (80.3 KB)
This second one was generated after tweaking a few tolerance values (I think "minimum cutting radius was the magic one here, but I also tweaked “tolerance” and “smoothing tolerance”). It works much better, there is no slowdown while cutting and the parts that come out are virtually identical (except for the burn marks on the first, and there’s one feature that’s a little less deep on the second one) hook 2.nc (9.4 KB)
Worked like a champ! Took my 9.5K file with erroneous moves and turned it into a <6K file with no BS moves. Nice work! Thanks! I did this on Mac OSX for testing purposes. I was posting the wrong file too, I will redo with the correct files in a sec and repost them.
OK so maybe not so perfect. Here are the screen-shots of what Ground Control shows with the files loaded up. Something went awry. I included the original and output .nc files below
Thanks Jason,
Yeah this thing is at very early stages. For example, I’m just figuring out that my tokenization is wrong, and that’s the start of my ‘pipeline’. There’s a whole range of uuuuugly gcode that’s perfectly legit, but it wouldn’t be able to tokenize yet (yet).
So sample very much appreciated. I won’t be publishing any of them with the project. But if you’d like to ‘release’ some then feel free to create a branch and send a pull request.
Thanks for your sample file. I’ve just finished changing the DedupLinear algorithm based on your sample file. So please git pull (or clone) and try again. Hopefully it works a lot better for you this time.
I also appreciate that this was my first non-metric gcode file, so it was a good test just for that reason alone.
Thanks for those files. I’ve tried processing both with the latest changes I’ve made, and I can see a drop in file size for both.
If you’re comfortable with grabbing the latest version of my code from GitHub and running things for yourself then please do that. But I’ll also post your ‘cleaned’ files back into this thread if you like.
You are welcome to use that file however you see fit, I am new to GitHub so I will have to decipher the branch and pull request stuff. I’m an old school techie, just getting into all of this…I have to say I like it!
I’m out until Tuesday but I will grab the updated build, reprocess, and report back when I get back. On the few files I played with, it reduced the estimated cutting time when I imported the parsed g-code back into Easel. It will be interesting to see if it truly reduces the cutting time once it is dialed in. I have several upcoming projects that will requires multiple identical objects so I will run some with and some without and give a true end to end test. Can’t wait.
I’ve updated the project structure and also redone the tokenizer to use a regex instead that will handle more ‘valid’ gcode (that it didn’t like before).
I was going to use regex anyway. But it normally requires taking psychotropic substances to wrap your head around the ‘regex’ way of doing things. So … anyway, done now.
git pull or clone and have a play with your favorite gcode files.
There is such a thing as regex golf - where you try and get the shortest regex possible to yield the correct matches. I think it’s probably played by the same people who think that SGML was a good idea.
I thought I was the only one who just didn’t get it and I needed some medicinal help and some mental reprogramming: perhaps a few days in concentrated meditation and some injections.
I’m an old school techie, just getting into all of this…I have to say I like it!