"We can not solve our problems with the same level of thinking that created them"
G-Code programming is wrong - and has been since 1980 when the IGES standard was published. With this CAD generated ASCII file, G-code programming SHOULD HAVE progressed to a CAD based, simple, accurate - walk in the park.
Subsequentially, G-Code Programming Software COULD HAVE been developed to perform the most repetitive tasks, making it even more simple, more accurate, and faster.
And when CAD was ported to PCs (AutoCAD-1982), G-Code Programming Software WOULD HAVE too.
SHOULD HAVE, COULD HAVE, WOULD HAVE - didn't happen.
SPOILER ALERT #1: A great deal of math has been done to calculate cutter coordinates and center coordinates for arcs for planar, turning, and 2-1/2D programmings jobs. Since 1980, this math could have been avoided by snapping points and lines onto parts and toolpaths in 2D wireframe CAD.
SPOILER ALERT #2: A great deal of money has been spent on CAD/CAM systems and Conversational Controllers for planar, turning, and 2-1/2D programmings jobs. Since 1980, much of this money could have been saved by snapping points and lines onto parts and toolpaths in 2D wireframe CAD.
SPOILER ALERT #3: CNC Construct is G-Code Programming Sofware developed for planar, turning, and 2-1/2D programmings jobs.
Manual programming has been around since NC machining began, circa 1950's. The process has not changed. Except for the use of text editors, manual programming has not progressed with technology.
Beginning with the trigonometry required to obtain cutter coordinates, through the completion of a G-code program, there are many problems to solve to advance manual programming into the computer age.
CAD is a powerful tool that gives the user the ablility to design tool paths. By generating points and lines, then exporting to the IGES file type, CAD could have solved the math problem of manual programming.