Iād like to see that run through GCodeClean. Iād really appreciate a sample of the code if youāre willing to share.
1 Like
Iāve had the convert G1 with +ve z-axis values to G0 for some time now. But I have noticed that theyāre doing -ve to +ve transitions on the z-axis with other motion as well. Now thatās kinda normal for many scenarios, but it seems theyāre doing it a lot. So Iām in the process of tweaking the G1 to G0 conversion to make it better able to handle these transitions.
1 Like
pardon my ignorance but im curious as to what GCode Clean does. I am a F360 user but am not sure what GCC actually does and how it would be helpful to me.
For the āfreeā tier of Fusion360 it was changed to emit only G1 codes instead of a combination of G1 and G0 codes. Depending on what youāre using the GCode with, G1 can be a lot slower than G0.
Among other things GCodeClean cleans up this behaviour, converting positive z-axis valued G1 back to G0 commands.
Thereās other tricks as well, although itās mainly about making sure of ābetterā GCode
2 Likes
In case md8n doesnāt jump in (edit: I see we overlapped) thereās a good description on github
Short answer, it can make your gcode run faster, optimize moving up out of the material being cut, and optimizing how arcs are sent to the controller. Plus it makes gcode look prettier. Try it on some small jobs and something other than your stash of precious walnut, and see what itāll do for you. I like to cut the same 5-10 minute job multiple times when tweaking parameters, while timing them and looking to see if cut gets screwed up fwiw, although a before/after test or two should be enough for GCC.
Sorry if this is too long, I tend to overexplain. While I tried GCodeClean on a normal (non-Maslow, an old 6"x9" Zenbot Mini) cutting job (number blocks for the grandkids) it really got interesting when I started doing diamond drag engravings (on a non-Maslow machine) with a CAM program that used G1 for plunges retracts, GCodeClean converted the retracts to G0 and saved me a fair amount of time. While these gadgets and handle a high XY speed I was concerned about fast Z moves (probably unnecessarilyā¦) whacking the diamond into the workpiece and cracking it loose from itās mount. Normally Iād just do a test to failure, but these things are relatively expensive. One peculiarity of the bits is theyāre spring loaded, and the cutting pressure is controlled by increasing the spring compression, which normal people would call depth of cut, and the required compression was around 5mm for the bit and material I was using. The machine was spending an awful lot of time moving down and then back up, GCodeClean cut the retract time to almost nothing and came close to cutting job time in half. Ideally it would rapid until the bit almost touches, slowly plunge until the diamond contacted the surface, and then speed up, but thatās way to specialized for a general purpose utility and is opposite of how youād use a spinny cutting bit.
Iām a big fan of G2/G3 arcs instead of short line segments. Besides a significant increase in gcode file size, and in the number of characters that have to be fired across the serial interface (at least for grbl like controllers, not an issue for, say, LinuxCNC), and (although I havenāt looked) could improved the lookahead of the movement planner. They also have the potential of executing arcs with step sized segments, making them as smooth as the machine can possibly go. GCodeClean will convert line segments to arcs which also made it very attractive
Iāve been interested in optimizing travel moves for a long time, admittedly not enough to take off my retired hat and trying to do it myself. Many CAM programs (3DP slicers are very bad at this) generate pretty stupid hopping around gcode, a lot of wtf moves instead of keeping travel lengths between cuts short. Adding this to GCodeClean is pretty exciting. My mental picture of the ideal optimizer breaks every file into an array of cuts, all with beginning and ending XYZ coordinates with a feed rate and then ordering them while maybe reversing direction (gets into climb/convention issues) to give the fastest cutting file. Less straightforward when you start thinking about depths of cut, you donāt want to cut the Z-10 paths before you cut the Z-1 paths above it, for example. The more common technique and easier technique seems to be breaking gcode into blocks separated by Z moves and then doing something like a TSP solution between blocks.
1 Like
Sure, although the files Iām using lately are in the 60K to 150K line range. Iāll see if one will zip up small enough to attach. Iāll see if I can run them through 1.0.5 and see what happens although there may be some honeydoās in the way today. I recently dropped a FluidNC/ESP32 controller into the machine (it was using an uno/cnc shield so fitting it was painless) and have been cutting what may become a table lamp with pine trees around the base and an elk over them (clipart that came with VCarveā¦) to give it a good test.
Iāve been doing some googling about arcs and rotary axes but not finding anything useful. The closest was a short comment on Haasās site that said they only do arcs on linear, not rotary, axes. Hmm, vectric offers both raster scan and waterline cutting, wonder what that might do. Iāve only been using raster.
gcode (as produced by many programs) can be very inefficient, making lots of
tiny moves, lots of up and down moves in one place (useful for drilling, but not
for anything else), etc. GCodeClean goes through your gcode and writes a version
out that produces the same result (within a very small error margin), but
optimizes it.
For the Maslow, which normally operates on the scale of ~1/100 inch, CAD/CAM is
happy to do things on the scale of 1/10000 inch, and when doing corners, will
split a corner into hundreds of lines of gcode, each moving the bit just a tiny
bit. When cutting wood, this results in burning of the wood at the corner as the
CNC machine takes more time to parse each line of gcode and the resulting
movement may be less than the resolution of the machine.
GCodeClean detects such tiny movements and removes them (among other things but
this is an easy example)
David Lang
1 Like
Thanks for the explanantions everyone.
I actualy use the paid version of Fusion so I probably have never encountered this particular problem with it. However, I absolutely can see this being a problem with other CAM packages and see now why GCC was developed. When I used to send out work to a cabinet builder to cut, he hated receiving designs that contained splines for a similar reason. His CAM would break a spline into 1000ās of straight lines. At best it would take 10x longer to cut. At worse it would start fires.
Anyway, when I stop doing commercial work with Fusion and I flip back over to the free version then I will need this solution so thanks for putting it together!
GCodeClean really doesnāt like my 4th axis Vectric gcode. VCarve recommends center 0 for rotary jobs, so all Z values are positive, forgot about that. It kind of defeats the whole purpose of zclamping. A seems to work OK, but it quit about 24K in. I tried to attach a zipped copy of the 130K line gcode file, but it wonāt upload, gets to 100% and gets an error message āSorry, an error has occurred.ā, also tried with the faceplant trick of renaming it to dot zipp, that failed the same way, as did the raw gcode. Hereās a google drive link that might work
OK - Got that downloaded, Iāll start exploring it soon
1 Like
It was developed because of this:
Thatās a 15 hour carving of a 15MB, 486K lines GCode file (to be honest I broke it into 15 files to carve).
Now with the current version of GCodeClean thatās reduced to a GCode file that is 3MB and 106K lines of GCode
2 Likes
486kā¦ā¦ I ā¦ I thought that was a file sizeā¦.
1 Like
Well ā¦ in a way it is 
1 Like
I used estlcam to generate the GCode from an SVG file. estlcam did an awesome job of path matching, but it generally generated line segments that were around 0.1mm long. With my maslow only processing around 10 lines of GCode per second that meant my actual feed rate was reduced to 1mm/s, so I needed a way of reanalysing GCode to take a more efficient approach (within tolerance limits).
GCodeClean gets travelling v1.1.0 
This is the first step towards doing file splitting and ultimately travelling path optimisation. So it gets a jump as a major point release to v1.1
Release v1.1.0 - Identify Travelling Ā· md8n/GCodeClean (github.com)
Need to get .net 6 for building GCodeClean yourself?
Itās now super easy on Ubuntu 22.04 (latest LTS of Ubuntu)
.NET 6 is now in Ubuntu 22.04 - .NET Blog (microsoft.com)
For Future Me To Do
GCodeClean runs on .net - not the old .net Framework that only ran on Windows, but the newer .net (formerly known as .net core) that runs on absolutely everything. .net 7 is about to go RC1 (Release Candidate 1) which means it is on the path to a final release.
For several years now āperformanceā (by all measures) has been a 'first-class feature` for each .net release, .net 7 features an absolute tonne of performance improvements. But one that caught my eye is this one: performance improvements in .net 7 - Native AOT
(warning thatās a very very long blog that just covers some of the performance improvements)
Native AOT - means āAhead of Time code generation, Native to OS and processorā. For GcodeClean this would mean having a single file, the executable itself, thatās compiled specific to a given OS (and processor) and would likely equal a drop in file size of 90%
Iām particularly keen on seeing what impact this would have for GCodeClean on Raspberry Pis.
But also, if thereās anyone wanting GCodeClean to run on Macs please let me know. With .net 7 it would be practical for me to start doing Mac specific builds again for the releases.
3 Likes
Iāll be downloading v1.0.1 this weekend and testing it for you. Any options you need feedback on?
1 Like
Not really anything specific - Iāll be very interested if someone gets it up and working on their own Raspberry Pi (or Mac), and the usual is if you get an āinterestingā result from it reprocessing a file.
The only new āfeatureā as such does not require any new switch. At the end of each cutting section GCodeClean will emit a comment with data about that section. This is a precursor to file splitting and then travelling optimisation.
GCodeClean goes to v1.1.2
Releases Ā· md8n/GCodeClean (github.com)
This is a first step in getting GCodeClean on .net 7 - plus I also replaced the library I was using for the console (terminal) behaviour to something a little newer.
Getting the build working for ARM (Raspberry Pi) with Native AOT (see above) looks to be a little tricky - so you wonāt find a pre-built binary for that yet. I may revert to cross-gen compilation for the Pi stuff (so not a single file, and quite a bit bigger) but weāll see ā¦
1 Like