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