The new file name will be -gcc.nc or similar. The clean command injects -gcc into the filename just before the very last part of the file’s name.
I’ll have a look in the code whether this is a misreported error.
So that error message only turns up because of this:
if (travellingComments.Count == 0) {
Can you PM me the original file, and I’ll give it a test
1 Like
Congratulations - you found a bug.
Remove the --annotate option and it will work.
I’ll figure out a bug fix sometime soonish (maybe)
2 Likes
Without --annotate you’ll get this, for example
G0 X7.757 Y0.036 Z3 (||Travelling||0||0||0||-0.058||notset||>>G0 X10.185 Y-0.332 Z3>>G0 X7.757 Y0.036 Z3>>||)
With --annotate however
G0 X7.757 Y0.036 Z3 (||Travelling||0||0||0||-0.058||notset||>>G0 X10.185 Y-0.332 Z3>>G0 X7.757 Y0.036 Z3>>||) (Linear motion: Rapid, X7.757", Y0.036", Z3")
For split to work, the Travelling comment has to be the last thing on the line. But --annotate is pretty much the last step in clean’s processing, so it puts its comment last. That’s what I’ll have to fix.
1 Like
Yay; I’m a winner!
Thanks for taking the time to solve the problem there! I included “annotate” mainly since it was included in the example prompt in the Readme, and I wanted to make sure things were working like the examples before taking things more off-road. I’ve tested without “annotate” on other files, and things seem to be working now as intended.
For my understanding, am I correct in that “Clean” basically just sorts through and re-formats the g code in order to be in the format needed for “Split” and “Merge” to work; “Split” then divides up the code into the smallest discrete chunks; and “Merge” then sorts through those discrete chunks, re-arranges and combines things where it can for more efficiency, then re-compiles them into a new g code file? I noticed that “Clean” alone often shrinks the g code down considerably (at least in terms of total lines of g code; I didn’t look to see if the overall file size or character count was significantly different before and after Cleaning).
clean is the original GCodeClean - it does the following:
- Preprocesses the file to determine the ‘preamble’, i.e. achieving an explicit entry state for the GCode
- Clean first phase
- Converts each line of GCode into tokens
- Eliminates line numbers (which are not recommended)
- Eliminates duplicate tokens
- Expands out all the GCode (for processing)
- Ensures only one comment per line
- Eliminates duplicates from the preamble and postamble (these are not yet written into the file)
- Pre and Postamble phase
- Ensure any file demarcation is correct
- Injects the preamble
- Clean second phase
- ‘clamp’ any positive z values
- Simplifies any travelling (+ve Z)
G0commands (removes superfluous travelling commands) - Converts any arc commands (
G2,G3) from using arc radiusR(not recommended) to usingIJ - Eliminates duplicate lines of GCode
- Replaces very short arcs with straight lines (within tolerances)
- Replaces lots of straight lines in an arc, with an arc (within tolerances)
- Clips decimal places to realistic values
- Eliminates duplicate tokens (again)
- Eliminates duplicate lines of GCode (again)
- Detects travelling, transition to +ve Z, and injects the
Travellingcomments - Simplifies multiple colinear straight lines
G1into single line
- Clean third phase
- Eliminates redundant tokens as per the minimisation strategy
- Annotates the file
- Reassembly phase
- Converts the individual ‘tokens’ back into actual lines of GCode
- And finally writes the whole lot back out to a new file.
4 Likes
I have noticed in recent experiments with “clean” - “split” - “merge” that my handy files (all profile cuts) end up with somewhat longer travel.
- Is that expected when the file is a set of profile cuts?
- Would it instead be appropriate to just use “clean” on profile cuts?
Just trying to wrap my head around ways to optimize my workflow.
Mahalo!
1 Like
There’s a reason why each major step outputs new files. So, you have the choice to just clean for example.
split on its own can be useful if you just want one specific part of the cut. The files that split generates are standalone GCode files, each with their own preamble/postamble.
And of course, merge tells you what the original travelling distance was, vs. what it achieved. So, you could set up a workflow that always does the three steps. But if the merge result isn’t satisfactory you can then easily grab the results of clean and go with that instead.
2 Likes
GCodeClean arrives at v1.4.1 - Preamble fixes
Thanks to a bug (mainly Fusion 360’s fault) reported by @MrN808, I fixed two oversights of mine in the preamble processing.
And here’s the result - Command line version at the moment though - I’ll try and get the GUI version updated soonish
3 Likes
And then I checked where the GUI version was at and realised I was in the middle of changing UI frameworks and never got back to it - sooooo - not soonish
2 Likes
Lee,
I think I found a bug in the linux x64 1.4.1 distro. It cleans and splits but the merge builds a file but it has 0 bytes. I’m using the exact same commands that I used with v1.3
-Tim
1 Like
Yep - there was a bug, which actually affected the way the Clean step fed information into Split - resulting in split quietly failing, which then meant that merge also failed
You can pick up the latest v1.4.2 at Releases · aersida/GCodeClean
1 Like
@md8n I would like to add this as an entry in the software library section of the wiki. It looks cool, I have never used it. is there anything that I should write about it? Can I list forum members here who are working on it? Who is making it?
2 Likes
@md8n is the guy you are looking for!
1 Like
It’s a CLI tool (runs from a command line) to ‘clean’ 3-axis (XYZ) GCode files.
It will often reduce the file size, the number of GCode lines, and potentially the ‘G0’ travelling times.
It has 3 operations,
clean- which does most of the worksplit- which will split a single GCode file into individual GCode files for each individual cutting path, andmerge- which can merge individual GCode files back into one file, and will try to reduce the travelling distance between the cutting paths.
As per the README.md in GitHub
A library and command line utility to do some ‘cleaning’ of a gcode (an .nc, .gcode) file. The primary objective is to be a GCode Linter, as part of that per line linting of gcode is already done.
We also have:
- eliminating redundant lines (within tolerances),
- converting very short arcs (G2, G3) to simple lines (G1), also within tolerances,
- linear to arc deduplication, converting several simple lines to a single arc,
- eliminate meaningless movement commands - especially G0 without any arguments,
- correcting G1 to G0 when the z-axis is at a positive value,
- clipping decimal places on arguments to meaningful values (as per the NIST spec),
per linelinting: splitting lines to match the actual execution order as per the NIST gcode spec, and then reorganising the ‘words’ on a line to conform to some common practices (but not all),annotatethe GCode with explanatory comments (optional), note that annotating a cleaned file means that you may not be able tosplitthe file later,- ‘soft’, ‘medium’, ‘hard’ or custom removal of superfluous tokens (
minimise). preamble linting: Adding a ‘standard’ set of gcode declarations, i.e. converting the ‘implicit’ to ‘explicit’.postamble linting: Similar to thepreamble, but at the end of the file (obviously).file terminator matching: Ensuring that if the file demarcation character%is used at the start of the file then it is also used at the end.splitting of GCode files into individual files, each with a single cutting path.mergeing of previouslysplitfiles, with some effort at ordering them to reduce the amount of travelling (G0) distance in total.
Forum members working on it - @md8n (LeeH), with a little update from @bar
4 Likes