I was always my intention to head down that path. Which is why there’s tolerance values as command line options, so that the user can fine tune the conditions for certain optimisations to be performed, or not.
One thing I can’t realistically do at present, although I am working on it, is to completely eliminate redundant G0 moves.
GCodeClean still works as a streaming processor. This is to keep memory consumption while it’s working to a minimum, and also to facilitate the ‘pipeline’ approach I’ve taken. But it makes it logically difficult to achieve any ‘look behind’ processing. Which is what’s needed to eliminate redundant G0 moves, and also to better process multiple short line moves into a single arc.
I notice there are a very few G-codes that your program does not document
G28.1 G28.1 means “store the origin position that the machine goes to when the G28 command is issued”. This position is stored into memory, but is lost if the machine is reset.
G30.1 G30.1 stores the current absolute position into parameters 5181-5186.
G38.3 G38.3 probes towards a target and stops on contact. No error is given if it fails to trigger the probe.
G38.4 G38.4 probes away from a target and stops on contact break. An error is signaled if the target position is reached without triggering the probe.
G38.5 G38.5 probes away from a target and stops on contact break. No error is given if it fails to trigger the probe.
G91.1 G91.1 go into incremental IJ mode In incremental distance mode, IJK numbers usually represent increments from the current controlled point.
G43.1 G43.1 is defined as a dynamic tool length offset that is not stored in memory.
I’ll add those ones in. They’re not in the NIST spec of course, but there’s a lot that’s not in the NIST spec, but that are unofficially standard (perhaps I should call that ‘common’).
I’ve just replaced the SSD in my laptop, gone from 128GB to 1TB, which also means I’ve done a complete, from scratch, install of Windows 10, and WSL running Ubuntu 20.04, with Visual Studio Code.
So now I’m trying to get Visual Studio Community 2019 (v16.7.7) properly back up to scratch as well, so I can get Resharper re-installed, aaaaand get onto my next plan which is to do a proper test suite.
I’ve been noticing several regressions with my work as I’m trying to fine tune certain behaviours, and that’s not a good thing. So it’s time for some proper tests.
I was looking at GRBL and ran their codes through your program https://github.com/gnea/grbl
An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino.
It accepts standards-compliant g-code and has been tested with the output of several CAM tools with no problems.
I own a Desktop CNC Mill and have been using Carbide Create to learn G-Code.
Reading straight G-code with no comments and looking up their functions is very difficult. I was completely thrilled to find GCodeClean especially since I earn my living at age 78 as a C# Visual Studio programmer, also. There is VSCode G-Code Syntax but so far as I know it does not create comments. Notepad++ has a G-Code Editor With Code Highlighting G-CODE_N.xml
There is a VS Code GCode coloriser, which makes it look prettier.
GCodeClean originally started life as a VS Code plugin, before I realised that a LOT more was needed. Ironically the only part of that plugin that’s left is the TokenDefinitions.json file with its GCode comments.
Now that .Net 5 has dropped I’ll be converting GCodeClean to .Net 5 before doing anything else, especially as I have to rebuild the solution files for Visual Studio anyway.
Then I’ll be working on building up a proper test suite for the various functions of GCodeClean. I’ve been introducing too many regressions as I’ve made changes so I need to sort that out.
After that I think I’ll start up a new thread for GCodeClean in the forum. Please feel free to keep commenting on this one until I get to that stage.
Attached is my FanucG-CodesMissingDescriptions.zip If you do not decide to add it to your json file, I will add it to mine. Please advise Thanks FanucG-CodesMissingDescriptions.zip (1.2 KB)
I see The NIST RS274NGC Interpreter - Version 3 August 17, 2000
Is there a newer one?
Under contract in 1983, I redesigned the financial accounting system for the National Institute of Standards and Technology Gaithersburg, Maryland
Likely not. That was also known as the enhanced machine controller (EMC) and was used to develop Mach (which eventually became Mach3, Mach4 was all new after Art sold out and retired) and EMC2 which became LinuxCNC after a trademark letter. Mach3 is still sold but unsupported, LinuxCNC is actively developed. So you can say that LinuxCNC is the latest version
Arcs seem to be busted, unless they suddenly moved to G1. This was a bas relief of a moose head, original stl from cults3d, although I stripped off a frame. Processed through kiri:moto. Options were
gcodecleancli --tolerance 0.01 --arcTolerance 0.05 --filename \gcode\MooseFinish.nc
I double checked, it was 0.8.9.1. Despite that the moose didn’t turn out too bad, finishing was 15% stepover but a fairly big 2 mm ballnose. Result’s 65mm diameter. A bit surprised it didn’t break either bit. My 3018’s modified to a 20K rpm spindle from the stock 8K and it’s rapids are set at 2500 mmpm.
And I suffered a small r-c inversion, confusing G1 and G0 for a while and didn’t manage to edit it all out, why some of that makes less sense than usual. OTOH you can’t expect too much from a moose with a swamprat problem. They don’t seem to have found the southern abode yet, although I’m on the lookout for their swamp alligator buddies.
| 