Now that you have some basics under your belt, it's time to talk about some of the complications that arise from different dialects of G-Code.
Some wag once joked that the great thing about standards is there are so many to choose from. So it is from G-Code. While much of it remains the same from controller to controller (setting aside alternatives to G-Code from things like Mazatrol, Heidenhain's Conversational CNC language, and others), there are important details and defaults you need to be aware of to understand the particular dialect of g-code your controller needs to be happy.
In terms of sheer numbers of users, the Fanuc dialects of G-Code are probably the most common among professionals and Mach3 among hobbyists. This is not to say they are better than other G-Code dialects, just that they are more common and so if you're going to talk to other machinists or move around from job to job and machine to machine, it may be helpful if you're familiar with those dialects and how they differ if your machine doesn't use one of these two controllers.
G-Code has an extremely long history. The first attempts at standardizing it came out of the Electronics Industry Association's RS-274 standard which has evolved to NIST's RS-274NGC standard. The original EIA standards work was begun in the 1960's but the first standard wasn't released until 1980. Even though there are now standards (ISO has one too that is nearly the same as RS-274), it isn't clear how many controllers out there are purely standards based. Indeed, many controls will claim to be some standard or other, but when you look closely at the details they're pretty non-standard.
How Are the Dialects Different?
G-Code dialects differ in a variety of ways. Most manufacturers have added their own little bells and whistles to make their dialect better for competitive and marketing reasons. For example, Haas has a series of special g-codes for pocket milling, as well as some special parameters and capabilities on some standard G-Codes. It pays to understand the special capabilities of your machine because they were probably put there to save time based on feedback the manufacturer got from its customers.
In general, we see the following categories of differences between G-Code dialects:
- Which G-Codes are Supported. Not all controllers support all G-Codes. For example, many early lathe controls do not support the G71 and similar roughing cycles.
- G-Code mappings. Sometimes the same function will be supported by different g-code numbers on different controls.
- Parameters and Macro Programming. Parametric programming with macros is something that emerged after the basic standards were in place. Fanuc Macro B is probably the most common standard for it. Many controls are very limited in their capabilities around Macro Programming and there are a lot of detail differences around exactly how Macros work.
- Parameters. Many G-Codes need additional information to do their job, so they use other words (letters) to collect that information. Exactly which words collect which information can vary from one control to the next.
- Formatting. Some controls allow G0 or G00. Some insist on G00. Some allow numbers with no decimal, others insist on a decimal or even a trailing zero. "1", "1.", and "1.0" are all variations that may be accepted, rejected, or required when specifying the number 1.
We'll talk more shortly about what all of this means, but for now, be aware that these differences exist. For simple programs and MDI use, obviously a lot of this won't matter. But, for writing complex hand-written G-Code or trying to understand why the G-Code your CAM program emits isn't quite right, you'll need to be aware of the dialect issues.
For purposes of this tutorial, unless we specifically say something different, we're going to assume you're running a Fanuc controller. If you follow along with our exercises with G-Wizard Editor, you should run a Machine Profile for the Fanuc Controller, preferably by downloading our canned profile. When you go to program for your machine, you'll need a profile properly set up for your machine!
Modal Behavior for CNC Controllers
Note the use of the word "Modal" with respect to IJK and R centers. There are lots of "Modes" in G-Codes. A "Mode" simply means the CNC Controller is remembering some behavior from the last time you told it what to do. People often think modally, meaning if you don't specify every detail, they fall back to assuming you mean to do things the way you did the last time you specified.
When you run a G-Code program in the GWE simulator, it shows you which modes are in effect in the little box under the backplot:
The controller's state and G-Code Modes are shown Below the GWE Backplot...
We'll talk more about how to run the G-Code Simulator in GWE soon, but for now, just be aware of where the currently active modes are shown below the backplot and in the little box to the right. The red outline shows the area that describes the current state of the CNC controller, which includes any modes. The screen shot shows the modes that are active at the very beginning of the Engrave program. You can see the following modes are in effect:
- G00: This mode means all motion is in straight lines at rapids speeds--the fastest your machine can move.
- G64: Best speed mode means the controller will make best efforts to move at the desired speed. An alternate mode is called "exact stop". More on that later.
- G20: Motions are in Inches rather than MM.
- G90: Motions are absolute rather than relative.
A lot of G-Code programming involves making sure the right modes are in effect before telling the machine what to do next.
If you're using a CAM package to generate G-Code, it has a Post Processor. The job of the Post Processor (or "Post" as most machinists call it), is to convert generic geometry moves in a dialect independent (and often G-Code independent) language to the particular dialect of G-Code your machine uses.
In our next article, we'll delve into Post Processors and how they work.
Before we do that, let's get G-Wizard Editor set up for your G-Code Dialect.
Setting Up GWE
Before we go too much further, let's talk about how to set up GWE for your machine's dialect. That will get you started down the road of using the right dialect as you use GWE as a cnc simulator (also called a g-code simulator, or a cnc or g-code verifier) for your machine. Presumably by now you have registered for GWE and downloaded and installed it. Refer to the GWE Setup page for details, and follow along with this video to get GWE set up for your g-code dialect:
The G-Wizard Editor Setup Tool...
Hopefully that makes sense to you.
It's inconvenient that all CNC machines don't use the same G-Code dialect, but it is a fact of life you may as well get used to sooner rather than later. Knowing that there are differences and having some idea what they are will make it easier for you to exchange information and g-code with other machinists. You'll want to make sure all of your tools are on the same page as your CNC controller in terms of having the same Post settings, otherwise you'll have all sorts of problems getting your G-Code working right.
As we go through each G-Code area, we'll try to go over some of the Dialect differences so you can make sure all your software is doing the right thing!
1. Set up and save a machine profile using the Fanuc Mill profile so you can follow along with the examples and exercises for this tutorial.
2. Set up another machine profile for your machine's controller, assuming it is not a Fanuc. Go through each option on GWE's Post page and set the options up as your controller calls for. This will give you a GWE machine profile to use when programming your controller.
3. Go through each post option in the GWE menus and get some idea what they mean and how they can differ from one controller to the next. It's good to have a notion in the back of your mind that these differences exist. You can use the GWE post options to look up what some of the possibilities are.
4. If you have a CAM package, select the proper Post for your controller and create some G-Code with the CAM package. Load the result into GWE and see that the toolpath backplot looks like what you'd expect in GWE. If it doesn't, there are either errors in the CAM package's Post, or you don't yet have GWE's Post set up to match the same g-code dialect as your post..
5. Get familiar with how your controller shows its current state, including the modes, axis coordinates, spindle speed, feedrate, and currently selected tool.