In testing your new gcodeclean-win-x64-standalone thatI downloaded on 02FEB2021, I ran a 54,950 line G-code program that I produced using Inkscape version 1.0 into Grblcontrol(Candle_1.1.7 ) on my SainSmart 3018-PROVer and it worked perfectly.
After running it through gcodeclean-win-x64-standalone, the output was 46,028 lines.
I observed that on every Arc motion command, my machine dropped out of program control to idle.
Deleting that line of Arc motion and restarting the run, caused it to drop to idle at the next Arc motion.
Here is a sample of the problem code: Please advise. Many thanks for your efforts.
(Start cutting path id: path965)
(Change tool to Default tool)
F100 (Set Feed Rate to {lengthUnits} or degrees, per minute)
G1 X280.106 Y20.024 Z-0.001 (Penetrate) (Linear motion: at Feed Rate, X280.106mm, Y20.024mm, Z-0.001mm)
F400 (Set Feed Rate to {lengthUnits} or degrees, per minute)
G2 X280.018 Y20.299 I2.504 J0.954 (Arc motion: at Feed Rate, clockwise, X280.018mm, Y20.299mm, Arc Offset: X-Axis, Arc Offset: Y-Axis)
G1 X280.028 Y20.337 (Linear motion: at Feed Rate, X280.028mm, Y20.337mm)
G1 X280.061 Y20.34
G2 X280.254 Y20.173 I-1.124 J-1.494 (Arc motion: at Feed Rate, clockwise, X280.254mm, Y20.173mm, Arc Offset: X-Axis, Arc Offset: Y-Axis)
From what I can remember from the NIST spec, this should occur if the defined arc (from the previous X,Y to the current X,Y using I,J as the center) is outside a tolerance value.
Imagine drawing an arc starting from the previous X,Y with current I,J as its center and it doesn’t quite line up with the current X,Y.
This could possible be occurring because your machine has a very fine tolerance on the mathematics involved (more than 3 decimal places).
You can try setting the --arcTolerance command line option to a much smaller value (i.e. an increased number of decimal places). This will result in less short line segments being converted to arcs.
Sorry to be such a bother but there was no README.md in gcodeclean-win-x64-standalone. I was able to find README.md in GCodeClean-0.9.1
I changed values from 0.1 to 0.000001 and the count of Arc motion: in the output did not change. Here are my results:
CLI.exe – --filename 22highstandard.nc --annotate --arcTolerance 0.000001
Outputting to:22highstandard-gcc.nc
Clipping and general mathematical tolerance:0.0005
Arc simplification tolerance:0.0005
Z-axis clamping value (max traveling height):0
All tolerance and clamping values may be further adjusted to allow for inches vs. millimeters
CLI.exe – --filename 22highstandard.nc --annotate --arcTolerance 0.1
Outputting to:22highstandard-gcc.nc
Clipping and general mathematical tolerance:0.0005
Arc simplification tolerance:0.1
Z-axis clamping value (max traveling height):0
All tolerance and clamping values may be further adjusted to allow for inches vs. millimeters
Unhandled exception. System.OverflowException: Value was either too large or too small for a Decimal.
at System.Number.ThrowOverflowException(TypeCode type)
at System.Decimal.DecCalc.VarDecFromR8(Double input, DecCalc& result)
at GCodeClean.Processing.Utility.FindCircle(Coord a, Coord b, Coord c, Context context) in D:\GitHub\GCodeClean\GCodeClean\Processing\Utility.cs:line 203
This is my setting for $12=0.002 Arc tolerance, millimeters. Factory GRBL Settings Reference says $12=0.002 (arc tolerance, mm) – This setting has to do with how GRBL does arcs by breaking them into many small line segments. Not usually required to be altered.
And I’m doing the reverse to cut down on the number of line segments 
If you are willing please send me your original nc file in a private message and I’ll use it for some testing.
Regards,
Lee
This looks like an ‘almost divided by zero’ error…
Just run cli.exe on its own and it will spit out the help info
22highstandard.zip sent as requested
Universal G-Code Sender gives this [Error] An error was detected while sending ‘G2X277.657Y16.49I-0.282J1.858’: (error:33) Motion command target is invalid.
**** The communicator has been paused **** When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than (.05 inch/.5 mm) OR ((.0005 inch/.005mm) AND .1% of radius).
yep that sounds like the problem that I thought it was.
My email software was giving me dramas yesterday, so I only got your file late last night my time.
Hopefully I’ll have a chance to look over the weekend.
I’d add a possibly irrelevant comment that Nick and the gcodetools crew abandoned it somewhere around 2010, and there was a moderate amount of discussion about whether it would actually work with Inkscape 1.0. Since nobody wanted to maintain the extension it’s completely unsupported and likely to be removed if anybody has problems. I used gcodetools somewhere around 2008 and while it worked OK after some source editing (on a Zenbot Mini with LinuxCNC) quit using it some months later. After over 10 years of abandonment there are better options. I like Carbide Create (free) and Estlcam (pay) but suspect that the currently supported krabzcam is a good free replacement for gcodetools and eliminates all of those inserted text boxes.
Still a good bug test, though.
Hi James,
It seems that it’s your original GCode that is at fault - mathematically it doesn’t make sense.
And I haven’t changed GCodeClean to fix up those kind of problems (that fact is it would never be able to).
So here’s the initial lines from your file (thanks for sending that through)
G01 Z -0.0006 F 100.0000(Penetrate)
G02 X 277.0458 Y 16.6422 Z -0.0006 I 0.7276 J -4.8048 F 400.0000
G02 X 277.7734 Y 16.5874 Z -0.0006 I -0.0000 J -4.8596
G02 X 277.9184 Y 16.5577 Z -0.0006 I -0.2133 J -1.4088
The first arc move is from X276.3182 Y16.5874 to X277.0458 Y16.6422 with the center of that arc offset from the first position by I0.7276 J-4.8048 which is the same as X277.0458 Y11.7826
Such an arc cannot be drawn. There’s something really wonky with the math used to generate those numbers. And there’s no way I could come up with any ‘magic’ in GCodeClean for it to guess at what the right I & J values should be.
I’d recommend not using that Inkscape for GCode generation anymore. But it is good at SVG, which is great for conversion to GCode.
estlcam will take SVG from Inkscape and produce really good GCode for you.
Inkscape’s gcodetools are a user written and contributed add-on and not part of the official codebase. It’s currently abandonware with no one willing to maintain it per the discussions I’ve read, and being considered for removal. It’s also an older version of Python which has a history of destroying compatibility with previous versions.
It’s semantics, but might be better to say that this past it’s prime user add-on should be avoided. Not inkscape’s fault or responsibility, and no effect at all on the base functionality.
5 files sent by email for your study. Thanks
I sent 6 new files by email. I made the G-code using .SVG files and Estlcam_64_11236 which I purchased as you recommended. It is easy to use.
I went back and re-did the math on the earlier file you sent me, and in fact it was OK. So we can eliminate that as a cause. Although I’m glad you’ve got estlcam because it does do a really good job processing SVG, DXF and even plain JPEGs into paths.
The GCode produced after running that first file through GCodeClean had been rounded down a digit (from 4 dp to 3 dp). But the resulting loss of accuracy was only around 0.003 of a millimeter at most.
Which officially your machine is fine with, according to one of your earlier posts.
I am reading CNCCookbook’s G-Code Tutorial G-Code Cheat Sheet + MDI: Your CNC Secret Weapon and trying to write my first program from scratch. CNC is modal, meaning it remembers a lot of things for you. In particular, the motion is modal. If we had just run a G00 and no other motion commands since, any coordinates we enter result in G00 moves. In this case, we depended on the prior G01 mode to still be in effect.
It appears your utility does not treat G01 as modal. Please advise. Thanks
Here is my program:
(Peck Drilling involves plunging the drill part way through the workpiece,)
(no more than five times the diameter of the drill, )
(and then retracting it to the surface. This is repeated until the hole is finished.)
G17
G21
G40
G49
G90
G94
F200
S0
M3
G00 X10 Y10 Z+25
S100
G01
Z+25
Z+10
Z+15
Z+5
Z+25
X20
Z+25
Z+10
Z+15
Z+5
Z+25
X30
Z+25
Z+10
Z+15
Z+5
Z+25
M5
G0 X0 Y0 Z+25
M2
Here it is run through gcodeclean
(Peck Drilling involves plunging the drill part way through the workpiece,)
(no more than five times the diameter of the drill, )
(and then retracting it to the surface. This is repeated until the hole is finished.)
G17 (Plane selection: XY)
G21 (Length units: Millimeters)
G40 (Cutter Radius Compensation: Off)
G49 (Tool Length Offset: None)
G90 (Set Distance Mode: Absolute)
G94 (Set Feed Rate Mode: mm or degrees, per minute)
F200 (Set Feed Rate to {lengthUnits} or degrees, per minute)
S0 (Set Spindle Speed 0 rpm)
M3 (Turn Spindle: Clockwise)
G0 X10 Y10 Z5 (Linear motion: Rapid, X10mm, Y10mm, Z5mm)
S100 (Set Spindle Speed 100 rpm)
G1 (Linear motion: at Feed Rate)
G0 X10 Y10 (Linear motion: Rapid, X10mm, Y10mm)
G0 X20 Y10
G0 X30 Y10
M5 (Turn Spindle: Stop)
G0 X0 Y0 (Linear motion: Rapid, X0mm, Y0mm)
M2 (Program End)
Hi Jim,
Sorry to take so long to reply. The primary problem with your code is that all of your ZAxis values are positive, which means above the surface of your workpiece. When that’s the case GCodeClean automatically converts all of the movement commands to G0.
Thanks so much for being patient with me. Universal-G-Code-Sender’s excellent Visualizer showed that problem but I was clueless as to why. (file attached). Candle’s Visualizer looked wonky but ran it. Estlcam just ran it upside down. It took me all day long to make those mistakes. Thanks again.
Did you get my email with the 3D printer G-code question?