Talk:G-code

message: 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)
thread_title: Someone deleted important information!

message: 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)
thread_title: Typo?

message: 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)
thread_title: Gerber

message: 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)
thread_title: Tool Changes

message: 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)
thread_title: Mistakes

message: 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)
replies: text: 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)
thread_title: G96

message: 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)
replies: text: 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)
thread_title:  Word 

message: 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)
replies: text: 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)
replies: text: Done. My edit summaries provide the explanations. — ¾-10 02:49, 14 October 2010 (UTC)
thread_title: NURBS

message: 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)
replies: text: 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)
thread_title:  Tool Header 

message: 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)
thread_title:  Requested move 

message: 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)
replies: text: Maybe block the page from IP edits for a time? — Dgtsyb (talk) 23:54, 29 April 2012 (UTC)
replies: text:  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)
replies: text:  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)
replies: text:  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)
replies: text:  I added a request for temporary semi-protection and added a request for XlinkBot as well. — Dgtsyb (talk) 12:08, 2 June 2012 (UTC)
replies: text:  Thanks. Glrx (talk) 16:25, 3 June 2012 (UTC)
thread_title:  Continual reinsertion 

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

message: 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)
thread_title:  GRBL chapter