Talk:G-code

Someone deleted important information!

Please restore: The section "List of G-codes commonly found on FANUC and similarly designed controls for milling and turning" as well as the section "Letter addresses", and "specific codes", and the "example program". They were deleted around July to August of 2023. The article is next to useless without the substance of example G, and M codes. Those sections make the article much more educational. Keep in mind machining is a technical trade, You can only dumb it down so much before you are saying nothing. — Preceding unsigned comment added by 98.127.21.16 (talk) 02:11, 29 January 2024 (UTC)

There could have been a more gentle way to redirect or explain common commands and such, but the editor did make a valid point, wikipedia is not a textbook/instruction book nor cheatsheet:

https://en.wikipedia.org/w/index.php?title=G-code&oldid=1168186120 is the particular edit you refer to.

you can still see the commands in the old page: https://en.wikipedia.org/w/index.php?title=G-code&oldid=1166786829#List_of_G-codes_commonly_found_on_FANUC_and_similarly_designed_controls_for_milling_and_turning or source the original book. (for the 27th edition, page 1272, pdf page 1593) its the first book in the bibliography section.

Tons of other resources seem to be dead, or unreachable from europe, this wiki page is very outdated and a mess anyway CodeAsm (talk) 13:41, 25 November 2024 (UTC)

Typo?

Can someone fix this "a post"? I'm not sure exactly what they mean: "that can output the appropriate G-code called a post for a specific machine tool." — Preceding unsigned comment added by 98.23.52.216 (talk) 23:09, 3 January 2019 (UTC)

Gerber

G-code and Gerber File articles seem to describe the same file format. At least googling for cnc "gerber" g00 g01 g02 and cnc "g-code" g00 g01 g02 gaves pages with similar lists. However I have little CNC experience to confirm this. --195.113.20.80 16:08, 26 Apr 2005 (UTC)

The Gerber format evolves from RS-274-D, but otherwise Gerber and G-Code have many differences, are used on different kind of machines and for different purposes. So better to keep these articles distinct. Lothartklein (talk) 10:42, 20 February 2009 (UTC)

Units

What about the units used in the G-code? I mean, where is it defined whether one uses inches, or centimeters, or some other unit? 134.58.253.114 10:53, 19 December 2005 (UTC)

As far as I know units are not defined - user has to supply it externally. Milimeters or (fractions of) inches are used. --Alvin-cs ✉ 18:37, 12 February 2006 (UTC)

I'm in my 3rd year at Deakin Uni Australia learning robotic engineering. All international specialists (except for a US specialist) that visited our division said it's best to design and program NC hardware to the world standards(ISO) which is Metric. I do recall one of the Italian lecturers from BLM Group stating it's ignorant and unprofessional to design NC equipment to anything other than ISO standards. So it's probably best for US engineers to stay in the imperial rutt.

There is a pair of G codes to switch between "inch" and metric. All CNCs have some way to switch between the two systems.

In general, G-codes are a simplistic progamming language. There are G code pairs to switch between not only inch and metric, but absolute and incremental coordinate designation. G codes are put into groups. The "motion" group includes G01 to denote linear departures, G02 to denote clockwise arc paths and G03 to denote counterclockwise arc motions.

There is only one CNC manufacturer that continues to use the EIA RS-274D standard for G code programming. All other manufacturers have adopted the international ISO standard. The two systems, while not identical, have significant overlap and commonality in how the G codes are used.

Just for clarity, G20 and G21 are the standard codes to specify units in inches or millimeters, respectively. Most machines will have a set of system variables accessible from both machine setup and parametric programs to permanently alter system defaults, one of which is inch/millimeter mode.

Inches vs. Metric: Almost all the large machine tools, both under manual and NC control, are still in inches. Example: The shipyard lathes used to turn driveshafts on large seagoing vessels, such as nuclear aircraft carriers. Many large floor and planing mills are still inches, as well. At least in the United States economy, these tools play a role in keeping some industries in inches. Why would you buy a 600 foot between center CNC lathe to replace the perfectly functional manual/NC one you already have, just to get millimeters? More importantly, where are you going to get it from in the first place? A floor mill with an 8'x8' table and 18' of pendant travel? Or a 15'x15' vertical boring lathe? Very few manufacturers are making equipment this large, and it is expensive to commission and transport. Lathes and mills that size were built in the 1920s and '30s, and are still alive and maintaining accuracy. No one wants to shell out the money for a new one just so they can switch over to metric. Some machines get converted to CNC. Even so, conversion is still an ineffective option for some of the larger tools, or smaller shops that work on big jobs. Or the machine design might prohibit it.

Outside very-large-job shops, automatic screw machines are another bit of old equipment many production shops use in quantity. Most of those are still in inches. A fancy CNC lathe or turning center isn't going to beat a screw machine in productivity, no matter how hard the lathe manufacturers try. They just can't get four second part cycles with one spindle and a turret yet. Screw machines are cheaper and produce more parts per hour. Some shops can afford to switch to CNC screw machines or rotary transfers, but that isn't common yet. So if the machines that are going to produce the part the cheapest are imperial, do you want to design in metric and have to submit a second set of weird/non-standard imperial drawings? Or are you just going to design your part in inches in the first place?

I really wish we'd just switch and use metric, because it would mean I don't have to stock and track of two sets of tools plus spares. But, in the end, it doesn't matter to the person making the parts if it's inches or metric - it matters to the machines. - Toastydeath 07:31, 26 November 2006 (UTC)

The CNC computer does not care about inches or meters or even furlongs or horse lengths. Here is how units work on a CNC machine:

We first have to start at the mechanical level. Picture a single axis CNC machine with only an X axis. That axis sits on some kind of linear guide and uses a ball screw to move the table. Now the pitch of that ball screw is where we start. If our hypothetical table has a ball screw with a pitch of 10mm per revolution, it takes 100 revolutions to move one meter. Now how do we know where the table is? We do that with an encoder mounted to the back of the motor which direct drives the ball screw. One motor rev equals 10mm of linear travel. The encoder is an incremental quadrature encoder with a nice even count number of 1000 counts per rev. Using quadrature encoding that turns into 4000 counts per rev. Now the motor is commanded not in meters or inches but encoder counts. Using the screw travel of 10mm per revolution and our 4000 counts, that gives us 10mm/4000 = 0.0025mm linear travel per encoder count. Now in the CNC software we say our units are mm and that 1mm = 400 encoder counts. This is how we define our primary units and counts per unit. So to move 1mm the CNC starts turning the motor until it counts 400 counts. This is invisible to the operator and only is adjusted by the machine builder. From there the CNC computer handles the feed rates and acceleration/deceleration. in G code, G1 X100 moves the motor 100 units, or 100mm in our case, which means the software knows to count 100*400 or 40000 encoder counts. In summary the base units of the CNC are based on the encoder and screw pitch. Using inches on the same system requires one to multiply inches by 25.4 to get mm. So in a system with 10mm/rev, to move 1 inch we move 1*25.4*400 or 10160 encoder counts. Simple. Changing units merely involves using a multiplier or divisor relative to the numbers of counts per linear unit of movement. That function is built into the CNC software and can even be adjusted (but is usually fixed for CNC machine tools). One can then imagine a similar imperial system but with a 5 revs per inch screw. And using our encoder example, that means to move one inch you move 4000*5 = 20000 encoder counts. Each count is 0.0001 inches. To move 10 mm you move 10*0.0393*20000 = 7860 encoder counts. Again, SIMPLE. Thaddeusw (talk) 21:11, 19 November 2013 (UTC)

Tool Changes

While the examples are interesting, they all lack one rather important thing: They never actually execute a tool change. T-- prepares the tool changer for the next tool swap, in the event the changer has such capability (most lower-end machines do not). M06 swaps the tool out. I have a few other concerns in this same area, and I'm going to pick on one program in particular. All suffer problems.

It begins like so: N1 X0 Y0 T01. This either goes to WCS 0,0 or doesn't move at all. We can't be sure, as the program isn't setting default modes. Then, it prepares the tool changer for a tool swap, but doesn't do anything. If the tool change DID execute via M06, the X and Y don't matter in the slightest, as the spindle on vertical machines needs only travel upwards to meet the changer. Both horizontal and vertical machines will move themselves to the tool changer in the event of a tool change, as absolute 0,0 can be anywhere on the bloody table. On top of this, no movement modes have been entered. So, even in the instance above, the machine doesn't have any of the information it needs to go anywhere (unless the machine enters a movement mode on startup, or you were running a program that actually did something beforehand). This program does nothing, moves the tool changer, and then does nothing again.

One generic, thoroughly explained program aught to be enough. Moreover, it should actually run on a machine if an example is to be included at all. Reducing complexity is necessary teaching new concepts, but not to the point where the information doesn't actually help anyone.

- Toastydeath 06:26, 29 November 2006 (UTC)

He used a lathe as a sample. On a lathe, a Txxyy (T xx=tool number - yy=offset number -- usually the first two digits designate which tool, the second two digits designate which offset. USUALLY, I said) ... anyway, when you call Txxyy, the turret immediately indexes to Tool xx, picks up offset yy, and bob's yer uncle.

Mills are different, they want an M to do the actual switch. Well, most of them. I'm sure there is one somewhere that doesn't ... M codes in particular vary from manufacturer to manufacturer or used to. Now we only have two or three controls and manufacturers, so not as much variety.

btw, I think that sample program is not very good. Turning G96 on when you are still two feet away from the part is stupid. In fact, G96 is stupid except for the finish pass. Kids these days :( 116.231.75.122 (talk) 12:46, 23 March 2017 (UTC)

Mistakes

Hello here are mistakes in program in G-codes. —Preceding unsigned comment added by 86.3.244.60 (talk) 18:10, 29 May 2009 (UTC)

example program

I think the example program is wrong. Every machine I've ever run will only allow one M code per line. Also, why would you optional stop after you've backed the tool away from the work, but before a tool change. I think the traditional way it's done is to have an optional stop between each tool change. Actually, never mind. The whole program is messed up. I think it's best just to re-write it rather than bitch about it here. I'll take care of it. SteveB67 (talk) 19:37, 18 March 2010 (UTC)

I wouldn't call the program wrong in general but I have to agree that I also tend to use one M code per block. Having said this, many CNCs are able to process more than one M code in certain situations. It all depends on the capabilities of the CNC and how it was configured by the machine tool manufacturer. Joergdiehl (talk) 23:42, 26 June 2010 (UTC)

[Update: The example program was revamped in late 2010, after the above comments. Still generalist (can't avoid that), but now a better example. — ¾-10 15:32, 26 February 2011 (UTC)]

I am just learning G-code, but it seems that the sample code is machining a cylinder of 1 inch radius, not diameter. GerhardRP —Preceding unsigned comment added by 129.236.254.107 (talk) 16:41, 25 February 2011 (UTC)

Ah, good eye. The program is correct, but there's something to be explained in order to interpret it that way. On most CNC lathes/turning centers, the X-axis is interpreted to mean diameter rather than radius. The machine takes care of dividing by 2. So in line N07, where you see X1.1, the tool is actually moving to 0.550" above centerline. So the tool is 50 thou (not 100 thou) above the intended finished surface. Which means that, if the bar is starting as 1-1/16 bar stock (1.0625), the tool is only 18 thou above the bar surface. The purpose of programming in terms of diameter instead of radius is to make it easier/more intuitive for the human. (The machine cares not for your puny human mental crutches.) This goes back even before CNC; among manual lathes, some have "diameter-reading" cross-slide dial graduations, and some have "radius-reading" dial graduations. (People throw around the term "direct-reading", but I don't like that term, because the hearer might hear "direct" in the sense that one thou on the dial equals one thou of slide linear distance [radius], or in the sense that you can think in terms of diameter, "directly" from dial to diameter. Better just to explicitly say which one you mean.) One might argue that diameter-reading introduces the complication that the human may *forget* that his .100" is actually only 0.50" above intended finish. But in general, two counterpoints: (1) Doing lathe work, especially manually, you grow accustomed to reflexively qualifying your thoughts with a conscientious "*per side*" and "*on diameter*" tacked onto the end of a number/distance-to-go thought; and (2) no matter which way you do it, there are some pros and some cons. Most Many machinists feel that diameter-reading is more desirable overall, and thus it's what CNCs are usually parameterized for. — ¾-10 15:32, 26 February 2011 (UTC)

Umm, the comment above is entirely wrong. He cannot say MOST machinists because a hell of a lot of us do NOT do not agree with this. The whole radius vs diameter programming fight has been going on for decades. A lot of us like to program with the real numbers, the opposite of what 3/4/10 says above.

But I amn't gonna bother changing the program cuz it don't matter to me, this is just wikipedia, not a real part 116.231.75.122 (talk) 12:52, 23 March 2017 (UTC)

Bullshit that it's "entirely wrong". The only single word of the whole paragraph that you consider wrong is that "most" could be changed to "many" to avoid quantifying. I fixed that single word. — ¾-10 00:49, 12 July 2017 (UTC)

G96

Why is G96 considered constant cutting speed whereas in the example program it is specified that G96 is variable cutting speed set with Sxxxx, which is NOT surface speed, but rather spindle speed.? —Preceding unsigned comment added by 99.251.107.193 (talk) 22:31, 19 August 2010 (UTC)

The comment as written in the sample program was confusingly phrased. The surface speed stays constant because the spindle speed increases while the diameter decreases (and vice versa). I clarified the comment. In G96 mode, the control automatically varies the spindle speed in order to maintain a constant surface speed as the tool tip gets closer to, or farther away from, the axis of rotation. The meaning of the S address integer varies depending on whether G96 or G97 mode is in effect. In G97 mode, the integer is interpreted by the control as meaning rpm (rev/min). In G96 mode, it is interpreted by the control as meaning surface speed, aka cutting speed. If G20 and G96 are in effect, it is interpreted as ft/min. If G21 and G96 are in effect, it is interpreted as m/min. One more piece of info: G97 is the default mode per system parameter if no mode is programmed. — ¾-10 22:57, 20 August 2010 (UTC)

Word

I believe there should be a brief description of what a WORD is before the term is used further down in the body of the text. —Preceding unsigned comment added by 70.70.254.196 (talk) 17:23, 18 September 2010 (UTC)

Word. (heh) [Those acquainted with AAVE will catch the joke there.] Anyway, you're right. It should be explained. The word "word" is being used in its comp-sci/prog-lang sense. As far as how that's precisely defined, I forget how to state it, but I have a ref or two that can help. I'll try to find time to look that up and explain/cite in the article. — ¾-10 14:13, 27 February 2011 (UTC)

NURBS

The reference to NURBS near the end of the first section is inappropriate. G0, G1, G2, etc, in the context of NURBS have to do with continuity conditions across adjacent curve segments and _nothing_ to do with NC G-codes. —Preceding unsigned comment added by 134.242.21.29 (talk) 19:55, 13 October 2010 (UTC)

No doubt you're right. I think the reason someone added the NURBS paragraph here originally was just as a kind of disambiguation effort, à la "the term 'G-code' is also used in NURBS terminology." It doesn't really work that way currently, coming at the tail end of the lead. It would probably work better as a hatnote sending interested readers to the NURBS article directly (Non-uniform rational B-spline). I'll go see about improving that. — ¾-10 02:44, 14 October 2010 (UTC)

Done. My edit summaries provide the explanations. — ¾-10 02:49, 14 October 2010 (UTC)

Tool Header

Is there a standardized header defined with tool information (form, diameter, spindle speed, X-Y movement speed, Z movement speed etc)? —Preceding unsigned comment added by 84.165.103.158 (talk) 09:14, 7 February 2011 (UTC)

If I'm not mistaken, I think you're asking about program documentation—i.e., methods and best practices for how people capture, store, and retrieve information about the program and tooling, beyond just the executable lines. This is done through a combination of internal and external documentation. The internal aspect is the info that's written into the program in the form of program comments. (The characters in G-code for enclosing a comment string, to signal to the machine that it should not try to execute the string, are parentheses.) The external aspect is covered by various things—first, of course, is the part drawing itself, and its materials list, prepared by the part designers (engineers, detailers); but beyond that there are things prepared by the CNC programmer that can have various names, such as the tooling sheet, setup sheet, methods sheet, routing sheet, and similar. This is explained more thoroughly in Smid 2008 chapters 48 and 49 (pp. 467-478). To answer your question about standardization, that has actually grown into an unexpectedly interesting topic thanks to the IT advances of recent years (since the rise of the Web, and especially within the past 10 years). The exact nature of program documentation methods varies by era and by company. It has always been in a constant state of evolution, and it is still evolving—and in recent years it is starting to get really freaky. For decades the semi-standardization has existed on the level of personal conventions (of individual programmers) and intra-company standards (which began as personal conventions and evolved into collaborative team standards). Things like company-standard safe blocks and introductory comments, company-standard methods sheets, protocols for how the operator's program tweaks get captured for future use next time that program runs, etc. As the end-to-end CAD/CAM workflow era evolves, the divisions between the drawing and the programming downstream of it can blur a good bit (used to be entirely separate concerns). Some general trends are that as the decades go by, the documentation relies less on hard copy and more on networks, and, more recently, that machine readability is strived for in addition to human readability. In recent years there has been a drive to really take all of this networking and machine readability to an entirely new level of inter-company standardization via things like industry-standard protocols (open, proprietary, or mixtures thereof) for serious data exchange and data mining. That's what projects like MTConnect are all about. Imagine having CAD drawings, tooling sheets, setup sheets, methods sheets, operators' notes and tweaks, and process data (e.g., load metering, vibration monitoring, temperatures) collected during running, all in XML form and beamed anywhere instantly to any API and any app that any crazy bastard can possibly cook up, and all mashed up into God knows what. Semantic shit and AI shit. Robotic machine tools that look at the part drawing, think about it for a moment, and ask the robotic warehouse what materials it has, and can you send some of that shit over in a truck that drives itself? So in an interesting sense, the standardization has been trending ever higher, even recently toward the level of XML schemas and APIs, but that just opens up a whole nother level of wide-open variation and creativity—a whole nother level where nothing is "standard" and all kinds of things are novel. Almost like language—like cavemen spent eons developing a language (standardizing documentation methods), but once they've carried that far enough, they can use the language to compose literature. They once struggled just to communicate "orange ... f-f-fire ... b-b-bad" to each other, but eventually they're writing whole treatises and stories about fire. The words that make up the story are all built using standardized rules of language; but the story they tell can be any wild shit that no one ever thought of before. It's actually rather mind-blowing. Seems to me we're currently about at the stage where the most advanced of us are painstakingly stringing simple sentences together. Wonder how many decades till robots are writing epic poems and shit. But to get back to the heart of your question, what you were asking about is the traditional mix of internal and external, human-readable program documentation—program comments (internal) and tooling sheet, methods sheet, etc (external). And now I must go eat dinner. Ta! — ¾-10 00:54, 8 February 2011 (UTC)

Will re-add unless a knowledgeable objection is explained

Deleted by User:Glrx from the "programming environments" section:

"Another recent evolution of the G-code programming environment is the integration of MTConnect, which makes the data of the G-code runtime environment available over internet protocol using open standards (XML schemas, XSLT, et al). For example, MTConnect wraps a block of G-code in XML tags and sends it to the mobile phone of the machine owner, who thus gets a real-time status update on the machine's operation."

Note that this is NOT the same text that was deleted the first time. It is a much-reduced mention with link, whereas the original version was, admittedly, forked versus the MTConnect article, as dawned on me after it was deleted. However, this new draft is short and unforked, so unless someone who is knowledgeable about CNC explains here in this talk thread what their objection is to this draft, it will be going back in, as this revised paragraph has NOT been reverted by two different editors. Thanks. — ¾-10 22:25, 12 October 2011 (UTC)

• Oppose. It's your burden to justify why the material should be included; don't shift the burden. You need a consensus here before you can include the above material.

The paragraph above is just a collection of buzz words and apple pie. Given open standards and wrappers and mobile phones, what's the benefit of informing a machine owner? The operator sees everything in real time; what does the owner care? How do wrappers help the programming environment? Why does a reader of an excyclopedia need this material?

Glrx (talk) 22:34, 12 October 2011 (UTC)

• Weak oppose The MTConnect stuff is interesting - I'm even looking at implementing it on my new laser cutter. It would certainly belong in CNC articles dealing anywhere near protocols. However I can't see why MTConnect is relevant (beyond a See also or a one-liner) to G-code. G-code might be relevant to MTConnect, but these relationships aren't always commutative. Andy Dingley (talk) 23:39, 12 October 2011 (UTC)

• Comment I don't care enough to edit war in the article namespace about it, but I'll just document here that Glrx, you're so wrong that you're embarrassing yourself. First of all, nothing I say is "just buzz words", although I am not infrequently accused of that by people who don't actually know enough about a given topic to fully understand what I'm saying or to see how it's relevant (you just joined the dullards club). Speaking of shifting the burden, it's not entirely my problem if YOU'RE ignorant. I can do my best to belabor the pedagogy in order to teach you what you don't know, but in the end it can't be me who is responsible for YOUR ignorance. Second, your other question just further shows how ignorant you are ("what's the benefit of informing a machine owner? The operator sees everything in real time; what does the owner care?"). I don't even have the time right now to set one random internet user straight on that; if you're that ignorant of the machining industry, good luck with editing WP articles about it. As for "How do wrappers help the programming environment?", you're right that they don't help it, per se, but they certainly affect it because from now on CNC programmers may be expected at times to know what's going on with the MTConnect interface and know how to control it. As for "Why does a reader of an excyclopedia need this material?", (1) for the reason just mentioned, and (2) why does any encyclopedia user need any info that's in the encyclopedia? Never know the exact why for each user, but we know that people use encyclopedias to find out more about stuff, and that's enough. So here's where we're at: (1) I'm going to let the baby (you) have its bottle (leaving that section as is) because I don't really give all THAT much of a fuck about overcoming one internet user's ignorance; (2) what we really had here was ONE person wanting to add a sentence and ONE person wanting to keep it out only to save face, not because it would HURT the article by being present; (3) the first person was not the underdog there—rather, it was logically a tie (although Andy's weak oppose later tipped the balance to oppose); (4) the second person can have the face; whatevs (goto baby getting its bottle); (5) I'm putting MTConnect in the see-also section, and if you don't think it can stay there, then YOU are the one who has an issue (wanting to change the article) that needs consensus from others, and like in tic-tac-toe, since I moved first on that particular WP:3RR instance, you've lost it before you started; that's the sad thing about WP:3RR. (See how others can play the wikilawyer game, too, when provoked?) OK, I'm leaving now because I don't like wikilawyering and I've done my little bit of it for 2011Q4 (hereby). In short, I've no doubt that you're really not that much of a dick but that you felt like saving face, and I assure you that I'm not a dick, either, but neither did I want to be a total doormat about letting you have some face, so I at least called you out on it here, and embarrassed you by letting you reveal how you don't know enough about the machining industry to be credibly reverting me. Sorry to let you make yourself look silly. I hope that if we meet again on another article we'll be able to collaborate successfully having gotten this one out of our systems. Later, — ¾-10 00:43, 14 October 2011 (UTC)

Lay off with the WP:NPA. If you're going to describe other editors as "the dullards club", then just be aware that other editors also keep such a list (see Talk:Monobloc engine) and you're on theirs.

Besides which, isn't ignorance the target for an encyclopedia? MTConnect is obscure, even more obscure than G-code, and no-one would be expected to know why it was significant, unless it was being adequately explained to them. This doesn't seem to have happened here. Andy Dingley (talk) 10:15, 14 October 2011 (UTC)

In hindsight, I see that I could have pre-empted this disagreement with a better edit summary on this edit. When I started the edit, I was "undoing" the previous deletion in the true sense of "undo"; but then during the edit/preview/edit process, I evolved into writing a much shorter, one-sentence mention-with-link of MTConnect, thus solving the problem that prompted the original deletion (i.e., that the old draft was too long and too forked). Once I'd created that second, shorter draft (which was valid on its own merits for inclusion here), I should have updated my edit summary before saving, to something like this (paraphrase): "OK, I see why you deleted that draft, and I'm replacing it with a much better, much shorter draft that avoids those problems, and simply mentions with link." If I had communicated that, Glrx would probably have judged the new draft on its own merits and allowed it to stand. But by having my edit summary start off with "Undid revision XYZ", I was (unintentionally) inviting an edit war in which I was casting myself as an edit warrior. Just wanted to explain here (belatedly) that that was not what I was trying to do (mere edit-war ping-pong). I'll need to watch out more carefully about updating my edit summaries before saving. — ¾-10 15:00, 15 October 2011 (UTC)

Mostly, I think you could have pre-empted this disagreement by avoiding the 20-line attack on another editor. Andy Dingley (talk) 15:23, 15 October 2011 (UTC)

Chronologically, that makes zero sense. — ¾-10 17:04, 16 October 2011 (UTC)

PS: Andy, you're one of the last Wikipedians I would ever take advice from on how to collaborate respectfully with others. My record is miles ahead of yours on that score, and I plan to keep it that way. I just lose my temper on rare occasions. Not much more than that. No offense, I just won't participate in any instances of being lectured by you on such a topic. And there are scores of other Wikipedians who would agree. — ¾-10 17:15, 16 October 2011 (UTC)

Requested move

G-code → RS-274 – This article is ultimately about the machine tool language specified in EIA RS-274. The language is frequently called RS-274 (or a close variant such as RS274). It would fit the naming convention used in other common EIA standards that are known by their RS-name: RS-232 and RS-485. I cannot find my copy right now, so I don't if if a hypen is used in the actual RS-274 standard, but my ancient copy of the serial "RS-232-B" standard shows hypens, so I expect the last rev of the machine tool language would be "RS-274-D". For our purposes (like RS-232), the revision letter is irrelevant. Renaming the the article to RS-274 would also side-step/minimize much of the "G-code" name issue. One of the external links even refers to "G-code and M-code" programming, so the mere G-code lacks precision. The NIST interpreter uses the name "RS274/NGC" instead of calling itself a G-code interpreter. The NIST doc says it reads "numerical control code in the 'NGC' dialect of the RS274 numerical control language" (page 1, first sentence). NIST uses the term "G-code" for a specific G and number combination (see pages 19-20). Glrx (talk) 21:53, 27 February 2012 (UTC)

• Support as nominator. Glrx (talk) 21:53, 27 February 2012 (UTC)

• Strong oppose per WP:COMMONNAME. Whilst I don't doubt that it's also known as RS-274, I don't recall ever having heard that name being used - certainly not in any common or conversational context (I don't write G code, I write programs that either write G code or else interpret G code and turn it into machine movements). Andy Dingley (talk) 21:56, 27 February 2012 (UTC)
• Strong oppose as above. Also, the name "RS-274" is not used in practice. This "requested move" is nonsense. Subtropical-man (talk) 22:48, 27 February 2012 (UTC)
• Strong oppose for several reasons. First, per WP:COMMONNAME. On this side of the pond, at least, if you talk about "G-code" on the shop floor, people know what you mean. If you said "RS-274", most machinists would say "huh?", and then when you explained, "you know, G-code", they'd wonder why you didn't just say that to begin with. Second, and more important, there are various dialects of G-code, and RS-274 is one of them. An analogy: Wikipedia has separate articles for French language and Standard French, and German language and Standard German. I view the proposed rename as analogous to proposing to rename the article "German language" as "Standard German". Not all German is Standard German, like not all G-code is RS-274. The "G-code > Implementations" section also mentions ISO 6983 and DIN 66025. Not clear to me how they fit into the proposed renaming plan. If separate articles were the plan, I would say, nah, just keep all variations of G-code in this one article, and leave it named as just "G-code" . — ¾-10 01:04, 28 February 2012 (UTC)
• Oppose What everyone else said above. I hear reference to "G-Code" every day. I've never heard anyone refer to it as "RS-274 code." If someone said it, I wouldn't known what they were talking about.gargoyle888 (talk) 03:20, 28 February 2012 (UTC)
• Oppose. G-code also refers to a family of proprietary CNC dialects that predated and survived the standard. — Dgtsyb (talk) 15:48, 28 February 2012 (UTC)

Continual reinsertion

From time to time, an IPuser will insert an advertising link, for example this edit. The link is to a page that starts, "NC Corrector, my G-code editor". The descriptive paragraph on that webpage apologizes that it is merely project:

NC Corrector v4.0, a free editor visualizer programs for CNC milling machines (G-code). Unfortunately development of this program is not moving very fast, due to the small amount of free time. At the moment, is able to render basic milling G and M-functions, drilling cycles, subprograms. Recognizes the 5-way problem arcs. There are exported in DXF format. Shows a tree, a variety of information about the program. (Machine time, path length, MAX MIN point of the trajectory, the number of segments, arcs, etc.) There is a hint of G, M codes when the mouse. Shows the point of the trajectory, the centers of the arcs. Displays an equidistant correction. There is a frame by frame navigation, with excretion in the status bar the current parameters of the program. There are display information about the item, when clicked on it with the mouse in the graphics window and much more ...

WP is not interested in advertising people's projects, and the site is not about G-code as a topic, but rather an application that the author wants one to download. It runs up against WP:ELNO 4, 5, and 11.

I've deleted the link on the basis of WP:BRD, but the IPs don't take it here. I'd appreciate it if somebody would revert the edit so I don't look like I'm engaging in a slow edit war.

Glrx (talk) 03:39, 29 April 2012 (UTC)

Maybe block the page from IP edits for a time? — Dgtsyb (talk) 23:54, 29 April 2012 (UTC)

It's slow enough that such a block would be overkill. If it is re-inserted, then a revert with a comment in the article not to re-insert without discussion on talk page might be appropriate. Glrx (talk) 20:33, 30 April 2012 (UTC)

Now it is up to twice a day. Can we request that the page be blocked from IP edits? — Dgtsyb (talk) 11:09, 1 June 2012 (UTC)

Yes, asking for temporary page protection seems appropriate (but we've had some good IP contribs recently). Go ahead and ask for it. We've been deleting this link since April 10, so a one or two month block might be appropriate. At worst, we get told to continue to play whack-a-mole. The IP range is huge (194.179.x.x, 178.92.x.x), so range blocks seem out of the question. Blacklist/Xlink are other options, but this is the only page being hit, so protecting the page is a minimal step. Glrx (talk) 16:38, 1 June 2012 (UTC)

I added a request for temporary semi-protection and added a request for XlinkBot as well. — Dgtsyb (talk) 12:08, 2 June 2012 (UTC)

Thanks. Glrx (talk) 16:25, 3 June 2012 (UTC)

Origin of the name "G-Code"?

An explanation of the basis of the name "G-Code" would be helpful. Does it have anything to do with Gerber? Or does it derive from Gnn being a subset of codes that are very commonly used to tell a machine what to do? Or?

The article says "G-codes are [...] any word in a CNC program that begins with the letter G." That makes sense, but if so, why does an article that also describes all the other letters go by the title "G-Code"? Gwideman (talk) 21:38, 6 March 2014 (UTC)

Regarding your first question, I don't know, but I think either of the 2 possibilities you mentioned are likely.

Regarding your second question, this article used to provide the answer, but someone deleted it for some stupid reason. I will go reinsert it for the benefit of readers who want to know, which is why it was included in the first place. — ¾-10 01:47, 7 March 2014 (UTC)

OK, thanks. Gwideman (talk) 01:50, 8 March 2014 (UTC)

Relevant discussion here: https://www.reddit.com/r/hobbycnc/comments/hdryki/what_does_the_g_in_gcode_stand_for/ /u/richcournoyer suggests that it may have to do with APT (programming language) predating G-Code and using the GO command. Other users in the thread refer to these documents https://www.americanmicroinc.com/difference-g-code-m-code.html#:%7E:text=What%20Is%20CNC%20G%20Code,the%20parts%20what%20to%20do. https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374 and say that it stands for "Geometric". --Kenblu24 (talk) 15:42, 22 June 2020 (UTC)

.gcode file?

where is that? the 3d file? RealCyGuy (talk) 14:33, 12 July 2018 (UTC)

.gcode is a plaintext format that contains the g-codes listed one after another, it is not a 3D file of an object but rather the toolpath. Some programs can use the toolpath and operation commands to generate a reconstruction of the object based on some assumptions about what the g-code file is written for. --2003:D6:170C:5A82:BCC3:6C66:317:53BE (talk) 10:31, 6 June 2020 (UTC)

True origins where? At MIT? Reference needed.

The history section states, "The first implementation of a numerical control programming language was developed at the MIT Servomechanisms Laboratory in the late 1950s."

No sources cited.

My casual investigation online finds no reference to the substance of a G-code language originating at MIT. The statement in the article doesn't assert that MIT had anything to do specifically with G-code, just a "first implementation" of something else. Nowhere does the article give the origins of G-code specifically, or why it had the favor of being adopted by anyone other than whoever invented this horror of software engineering. Any other NC or robotics work of that era has plenty of claimants who take credit. Similarly imperfect language projects like FORTRAN or BASIC have their authors credited.

I've spent some hours researching the technical lore online, and all I can find are old hands talking about G-code being first encountered as a quick hack to run the early Gerber drilling machines. Nobody seems to remember where it actually started as a concrete thing.

Sure hope this unsourced assertion is not some MIT pranksters up to WP mischief.

Can we know today who is responsible in history for starting G-code? Richard J Kinch (talk) 06:17, 28 March 2019 (UTC)

"whoever invented this horror of software engineering" — in the 1950s, machines were not software controlled but rather finite state machines. Even in the 1960s and 1970s, instruments and machines were FSMs with fairly simple designs. Test equipment controlled by HPIB/GPIB would shift ASCII digits into a register; a single alpha character would specify a destination for the shift register. It wasn't until the middle 1970s that microprocessors enabled the switch from FSM to software/Turing machine.

See History of numerical control.

I cannot find my copy of EIA RS-274, but I think it pointed to MIT for its origins.

In looking over the early MIT reports, I didn't find a description of MIT's paper tape format, but the reports give some history and fit with my dim memory. The machine tool and APT development reports explain the issues. Some APT flow charts refer to "X-codes". The initial machine tool control tests were for one axis; that was later extended to 3 axes, so X, Y, and Z codes would make sense, and the term X-code would be natural. Feed rates and spindle speeds were also specified to the machine tool. It could easily be that MIT's milling machine did not have any G-code commands because it only did linear interpolation. One could dispense with G0 and G1 distinction by simply changing the feed rate (which was already required).

Ward, John E. (15 January 1960). Automatic Programming of Numerically Controlled Machine Tools (PDF) (Report). DTIC. AD241754.

Glrx (talk) 17:46, 26 April 2019 (UTC)

So the trail from EIA RS-274 to X-code to MIT is as follows:

RS-274-C, which was approved in April 1974, unified two different EIA standard: RS-273 (Straight Cut) and RS-274 (Contour Cut), both of which had initial publication in January 1963 (see Library of Congress copyright filings).

The EIA RS standards, which governed members of the EIA, were essentially copies of earlier AIA National Aerospace Standards: NAS 943 (Straight Cut) and NAS 955 (Contour Cut). NAS 943 was approved in 1960 (as per the AIA Annual Report, available online). The EIA governed Electronics manufacturers, while the AIA governed Aerospace manufacturers.

Those standards are predominately based on the two leading Numerically Controlled mills during the APT work: the Giddings & Lewis mill (trademarked as the Numericord) which used a combination of General Electric and Concord Controls controllers. The second system was the Kearney & Trecker mill, which used a Bendix controller. Both machines had detailed papers published at the Eastern Joint Computer Conference in December 1957 (proceedings available online). The Bendix solution used "R-codes" to describe operational modes (essentially G-codes) and another set to describe auxiliary on/off functions (essentially M-codes). The Giddings & Lewis system used "X-codes" which also described operational modes and auxiliary on/off functions. These are the X-codes described in the APT flowcharts. The assertion that these were the two leading NC mills in the mid-50s can be found in Forces of Production by David F. Noble. The same book contains significant content as to why Bendix became the preferred solution during the standardization process, which was driven as a requirement by the US Air Force.

The X-codes are better documented in US patent 2963137 "Controls for a typewriter and associated apparatus" (the patent title is somewhat misleading - this is a numerical control patent). The patent assignee is Giddings & Lewis, but the four inventors (McDonough, Susskind, Grossimon, and Lee) were all MIT staff attached to the Servo Lab. Giddings & Lewis poached the entire MIT numerical control staff (with the exception of Susskind) to form Concord Controls at the beginning of 1956. Note that the same team worked on the original MIT NC Mill, which was finalized in 1952. Bendix licensed the two patents that were generated from the 1952 mill. It's unknown if the idea for X-Code occurred while the group was at Concord Controls or while at MIT. They would have been influenced by activities in the field of Automatic Programming occurring on the MIT Whirlwind computer in 1954 (Susskind was on the Whirlwind staff). Two Automatic Programming activities, well-known in Whirlwind circles, were the "CS" and "SS" programs, which both utilized labels that were called "mnemonic alphadecimals", which consisted of a single alphabetic character, followed by up to 3 decimal digits, the same as the X-Code format. (documented in MIT Report R-233, "The MIT Systems of Automatic Coding", C.W. Adams, available online)

The Bendix R-codes were encoded on punch tape in their own special block, so there was never an appearance of an alphanumeric code, such as "R00", although the codes were labeled "R" on the part programming sheets (see the 1957 paper). The Giddings & Lewis X-Code, however, appeared exactly as G-Code would later be used. There is no relationship between the operational code numbers between X-Code and the later G-code. It's unknown if the same can be said for the auxiliary functions, as they are deliberately not documented in the 1957 paper, nor the 1956 patent - other than the Program End function which was encoded as "X00", the same as the later "M00". (see the part programming sheet, Figure 5, of the G&L patent).

Alvonruff (talk) 15:17, 16 September 2021 (UTC)

FANUC sources?

Sources: Smid 2008;<ref name="Smid2008">{{Harvnb|Smid|2008}}.</ref> Smid 2010;<ref name="Smid2010">{{Harvnb|Smid|2010}}.</ref> Green et al. 1996.<ref name="Greenetal1996">{{Harvnb|Green|1996|pp=1162–1226}}.</ref> This line appears in the article, but there is no link to the actual publication, there is no title to the publication... and worst, it's not something that can be googled for easily! This needs to be fixed.

GRBL chapter

I miss an article or other description of GRBL in the Wikipedia, so I propose a sub-chapter 'GRBL' under 'implementations'. Okay? --Edoe (talk) 11:02, 14 February 2021 (UTC)