GCodeClean hits v1.0.1 🎉

[md8n]

Finally!!

The last two things holding me back from declaring GCodeClean has reached v1 I’ve tackled and resolved:

• Line to arc deduplication works for more then just two line segments - This has actually been working since 0.9.6 but I didn’t have a decent test for it - now I do.
• ‘Postamble’ - ensuring that a GCode file finishes nicely with an M2, M30 or % as required. Plus injecting a G0 Zx (where x is the zClamp value) if one is needed before the M2 or M30

The pre-built binaries for Windows, Linux and Linux-ARM (Raspberry Pi) are now available.

So now what?

Getting this far has got me thinking about what to tackle next, perhaps coming up with a road map of housekeeping needs, possible new features, as well as asking for suggestions, and tackling some of the pain points.

Housekeeping

• File pre-scan - There’s some key info in the file, such as what measurement units are in use, that are needed everywhere by GCodeClean, so doing a first pass through the file for all of these values would be very useful and help me simplify some of the code.

New Features

• Inject blank lines before significant actions - Such as tool changes, tool raises, the ‘temporary’ tool stop commands M0, M1 and M60, and maybe some other stuff.
• File splitting - Split a file into discrete and complete GCode files for every ‘significant action’.
• More support for other GCode syntaxes - GCodeClean simply ignores things it doesn’t understand just letting them go right through, but that does mean that they don’t get any attention to make sure they’re at their best. There’s lots of other flavours of GCode that could benefit from a little more love.
• Unit conversion - Change from inches to millimeters. And maybe the other way if you buy me
• Path optimisation - Yeah this one is a real biggy, and for practical purposes I’d want the ‘File Splitting’ done as a precursor for this work. In effect this is solving the Travelling Salesman problem which is one of the hardest problems in computer science, but there are ways to do a ‘not so bad’ solution to this problem.
• Path inversion - swap the start and end of a cut

Suggestions

• What have you got?

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. But maybe I should add my own UI?

[dlang]

you talk about us buying you do you have a way fo us to do so? (patreon
account or other?

David Lang

[md8n]

I have a ‘wise’ account, which already includes a USD account. That would work for

[Arnd]

@md8n

Finally!!

[…]

New Features

• Path optimisation - Yeah this one is a real biggy, and for practical purposes I’d want the ‘File Splitting’ done as a precursor for this work. In effect this is solving the Travelling Salesman problem which is one of the hardest problems in computer science, but there are ways to do a ‘not so bad’ solution to this problem.

Wait, you evaluate the gcode and optimize the “travel”/cut code?!

I need to test this with my CamBam code because most times i have the impression that CamBam never met a traveling salesman Optimized “routes” would be extremely important especially with the maslow.

But i am very impressed anyway!

[md8n]

GCodeClean works as a line-by-line optimiser, technically it is a streaming processor. I did it that way so that it would keep its memory consumption to a minimum. So that means that I’ve been able to do optimisation of the cutting paths (to a tolerance), but optimising the travel isn’t possible that way, because obviously you’re shuffling entire sections of the GCode around.

So that’s where my thoughts of having functionality to split the GCode into multiple discrete files, would then facilitate being able to recombine them in a different order.

[Arnd]

[quote=“md8n, post:5, topic:17995, full:true”]
GCodeClean works as a line-by-line optimiser, technically it is a streaming processor. I did it that way so that it would keep its memory consumption to a minimum. So that means that I’ve been able to do optimisation of the cutting paths (to a tolerance), but optimising the travel isn’t possible that way, because obviously you’re shuffling entire sections of the GCode around.[/quote]

Yes, thats why had been asking. Doing a full “post traveling salesman” on gcode should be worth a masters degree

So that’s where my thoughts of having functionality to split the GCode into multiple discrete files, would then facilitate being able to recombine them in a different order.

I understand. Thx for answering.

[TimS]

It seems GcodeClean removes tool changes.

Using carbide create, it always generates a tool change in the beginning and after cleaning it is removed, also seems like other tool changes were removed. Used minimise soft and zClamp

Is it possible to leave this as an option?

[md8n]

@TimS

Using carbide create, it always generates a tool change in the beginning and after cleaning it is removed, also seems like other tool changes were removed. Used minimise soft and zClamp

Interesting. There’s no code in there to specifically remove tool changes. Do you have some sample GCode you can share?

[TimS]

Sorry for the delayed response, life sometimes gets in the way.

It looks like the T command remains but the program stops were removed.
Cappy Vee.nc (252.0 KB)
Cappy Vee-gcc.nc (288.5 KB)

[md8n]

@TimS

It looks like the T command remains but the program stops were removed.

You’re correct, I can see that the M0 “temporary stop” - i.e. ‘pause’ has been removed. Thanks for those files - I’ll investigate

[md8n]

And found the problem with this line:
M0 ;T10
While using a semi-colon to start a comment is common, it is actually illegal according to the official NIST spec. (All comments are supposed to be in parentheses). So the above line should have read:
M0 (T10)
But like I said, semi-colons for comments is very common. I did support it for whole line comments, but not end of line comments, which I’ve changed.

[md8n]

Thanks to @TimS I found another sneaky bug hidden away. And while I was testing that out another one was revealed. I really should add some more tests…

Plus I did some refactoring (first bit of housekeeping, not in the list above).

And the result is:
v1.0.1

[md8n]

GCodeClean hits v1.0.2

This release ‘kind of’ adds the file pre-scan from the road map above.

What I did in the end was to split the processing into 3 phases, with the first phase leaving the GCode in a position where it could be reliably ‘scanned’ to get the length units (inches or millimeters). And with that the code can then constrain the tolerance and clamping values.

Release v1.0.2 - Pre-scan · md8n/GCodeClean (github.com)

[md8n]

GCodeClean takes a little step v1.0.3

This release was supposed to be about preparatory steps towards injecting blank lines before significant actions, and file splitting from the ‘road map’ above. But, of course, other things came along …

The workflow has been split into more ‘phases’ of processing, although there’s still three ‘main’ phases.

There’s now an additional PreAndPostamblePhase that handles injecting the preamble and postamble contexts and file demarcations. As well as a ReassembleLines phase that does the final conversion of the Lines into GCode text.

There’s also a dedup pass to remove redundant context statements (this does not include redundant movement commands although they are obviously part of the current state or context of the machine).

Along the way I also found an oversight in how GCodeClean handles negative Z values. If there’s a negative Z value, but the movement command is G0 then it should really be converted to G1, at least as a first best guess. And this is what is now done.

And of course a new test, and changes to an existing test to cover the above changes.

Release v1.0.3 - Dedup Context, and fix for -ve Z with G0 => G1 · md8n/GCodeClean (github.com)

[md8n]

But wait! There’s more!

GCodeClean dances on the walls v1.0.4

tl;dr - You probably want to get this one if you work with nasty GCode.

It was all supposed to be so simple …

As I was running through some tests (using a particularly nasty bit of GCode - thanks @cmullins70 Z-Axis Plunge of Death - #4 by cmullins70) I noticed that certain curves (from linear to arc deduplication) were scrambled, although most of them were fine.

And down the rabbit-hole I fell.

This particular nasty bit of GCode used multiple coordinate planes, so not just G17, but G18 and G19 also. Why? Really bad CAM programming I suspect, from the looks of what it was used for.

However, while GCodeClean has the maths to support this, I never really got it working, simply assuming that there would only ever be one coordinate plane in use for a whole file.

So now that I have the preamble context in a really sweet spot, I could get each function that needed to know the coordinate plane to define an initial context, and then update that line by line (of GCode) to always have the correct coordinate plane with which to feed into the processing. Hey presto , linear to arc dedup suddenly works properly for all coordinate planes.

But that left another issue (cover your children’s ears for this one), it’s totally legal to change units in a GCode file, going from inch to mm and back again. Why anyone would want to do this is beyond me (utter perversity I’m guessing), but ‘supporting’ this abomination was ‘the right thing to do’ with regard to making the code cleaner and sticking to the NIST spec. So here it is…

Release v1.0.4 - Handle a changing context everywhere · md8n/GCodeClean (github.com)

[md8n]

… and here’s the steak knives …

GCodeClean skips a step (or two) v1.0.5

Sometimes bad CAM will encode cutting paths (G1) that’s actually above the surface of the work (i.e. they should be G0), maybe abuse of cutter compensation etc., but generally 'just bad programming’™️

Running the zClamp pass over the GCode will convert all such bad cutting paths to G0. Then this functionality can do its work to eliminate all of the intermediary G0 movements that do nothing but waste time.

There’s a new command line option --eliminateNeedlessTravelling with a default of true, including this option and setting it to false will let you keep these lines if there’s some perverse reason (like bad CAM) that means you need to keep them.

Release v1.0.5 - Eliminate Needless Travelling · md8n/GCodeClean (github.com)

[TimS]

Does this mean path optimization?

[md8n]

Not yet. Next steps are identifying logical breaks in the GCode (the inject spaces for key steps / file splitting ideas), and then once that’s done looking at travelling path optimisation.

[mooselake]

GCodeClean may have become very interesting to Fusion 360 free users

And if I haven’t said it before, thanks for all your time and a great product

[mooselake]

I meant to ask (or did and forgot) what happens if you run rotary axis (my machine is XZA) gcode through it? Other than arcs it could be handy, but I may have the only round machine here, it’s a smaller user base.

I have absolutely no idea what happens if you try an arc with X and A without gcodeclean, VCarve doesn’t seem to generate them with its Y to A wrapping, but the rest of GCodeClean should be just fine. OTOH it might be fun to try one and see if the controller starts smoking