On 05/12/2013 10:34 AM, andy pugh wrote: > On 12 May 2013 18:08, Rafael Skodlar <ra...@linwin.com> wrote: > >> If the operator does not understand complex operation, that's precisely >> why a subroutine should be used IMO. Granted, I do not know much about G >> code and machining in general as my work mostly revolved around >> computers and connections to "other stuff", sometimes CNC. However, code >> is code, it automates processes and minimizes redundancy if written >> properly. That goes for CNC machine operations or OS administrative tasks. > > I think that you might be mistaking G-code for a programming language…
It is a programing language. "G-code is the common name for the most widely used numerical control (NC) programming language, ..." see http://en.wikipedia.org/wiki/G-code It was created to program machines that make parts over and over again. Computers were very limited in computing power and memory in those days so the code was very terse and limited. Some of the CNC machines did not have computers at all. There was some electronic logic to read the paper tape and drivers to flip relays, breaks, clutches, etc. Seen that. "G-code began as a limited type of language that lacked constructs such as loops, conditional operators, and programmer-declared variables with natural-word-including names (or the expressions in which to use them). It was thus unable to encode logic; it was essentially just a way to "connect the dots" where many of the dots' locations were figured out longhand by the programmer." Unfortunately that did not improve much over the years. There is no longer reason to keep saying G "tis" or G "that" when a more powerful descriptive language could be derived for the same results. Improvements made to G-code were small and show it's age, just look at M30. "Since about the mid-2000s, the era has finally arrived when "the death of manual programming" (that is, of writing lines of G-code without CAD/CAM assistance) sometimes seems to be approaching. However, it is currently only in some contexts that manual programming is obsolete." CNC is stuck in it's own "assembler age". If the industry switched to a modern intermediary language like python, you could say from geometryset import circle from geometryset import square circle = circle(x, y, radius) circlePoints = 5 # number of holes on the circle startingPoint = 0 # 0 degrees from X- axis drillDepth = userInput drill(circle, circlePoints, startingPoint, drillDepth) squareX = 10 squareY = 15 squareSize = 55 squareAngle = 45 drill(square, squareX, squareY, squareSize, squareAngle) to drill number of holes in the circle and in square. You could add user input for each variable to make it more flexible. help(geometryset) square, circle, star, .... help(drill) Much simpler to learn and remember than Gxx with it's limitations. It's all vector graphics at the end. Operators could learn it just as fast as they learn G-code. If you wrap this into functions, i.e. subroutines and stored them into library, you could run complex jobs from the command line very fast. I'm sure it's been done in some form but G-code keeps being the focus in discussions. G-code shows it's limitations in 3D printing and is not something that masses will adopt for quick "one of a kind" products. > > It can be used as one, certainly, but then so can Postscript. > By that logic, we would program web sites code in assembler. But then millions use inches and feet even when they tweet ... -- Rafael ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
