Those of you who are relatively new to CNC but who have been around more experienced CNC’ers have probably wondered why they always add a decimal point in the GCode, even when there’s nothing following the decimal. For example, to go to 5 inches (or mm in metric) right of the origin, they will enter “X5.”. Why add that pesky decimal point when “X5” is what we all learned in grammer school?
We’re here to talk about why it is a good, perhaps even an essential habit, to get used to always putting a decimal point, even when there will be no digits to the right of it. I was recently talking to a gentleman who had upgraded from a Tormach PCNC mill to a Haas Mill. He was trying to do a test cut on a file he’d used in the past on his Tormach. It was a bas relief 3D profile of a knight or horse’s head. A quick backplot in G-Wizard Editor with the Haas post selected produces this output:
You’ve probably seen the file running around yourself. Nothing too special here. But this fellow stated that the cutter would periodically jump off the toolpath with terrible results on the final part. He stated that he understood there was some difference between the Tormach’s g-code syntax and the Haas syntax. By now you must have guess it has to do with decimal points, since that’s what this article is about.
It turned out that certain coordinates in the file lacked a decimal point. By default, Haas machines (and many other CNC’s, but not the Tormach) do something quite interesting with no decimal point–they divide the number by 10,000! In other words, they assume that “X5” is the same as “X0.0005”. You can imagine how crazy that can be to experience in a program without being prepared for it. Dropping the decimal accidentally on an MDI move can also be pretty scary. After all, “X5” and “X0.0005” are pretty far from each other so the machine is going to a very surprising place.
So why do Haas and others do this? It certainly can seem like a bad idea if you get bitten by it. The answer is that it is for compatibility with very old GCode Dialects that worked that way. Personally, I don’t much care for it, but I had gotten in the habit very early in my GCode career of typing that extra decimal point just in case.
If you’re not yet in that habit, or more likely, if you have some strange GCode and want to check it as this gentleman did, what can you do? It turns out G-Wizard Editor can help with this, but to do so, we have to turn on some optional checking. GWE was built to check for as many problems as possible. Most simulators just put out the backplot and if it looks good, they let it go. Programs that will alarm out on the machine or do worse come out looking fine in these programs. We wanted to do better for GW Editor, so it has a lot of checking. Some of it is optional for greater speed. Detailed checking of number syntax is one such option.
To get it going, you have to change an option:
The number checking option is circled in Red. Turn OFF the checkbox to add more number checking…
The number checking option is circled in Red in the screen shot above. Turn OFF the checkbox to add more number checking. When the box is checked, G-Wizard Editor will take any number that’s valid to a human without considering the peculiarities of specific GCode dialects. We do this to make the program faster in general use, but to pick up these subtle decimal point problems, you’ll want to unclick the box to enable full checking. Doing so not only adds more checking, it also enables G-Wizard to process the numbers without decimals more like the native CNC machine. You can see there is a field in the lower left called “Divisor.” Depending on which letter is involved, this can change. For the rotary A axis, the default value for Haas is 1,000. So it divides the A value by 1000 if there is no decimal. For the X (which also governs the Y and Z words), that value is 10,000.
If you wanted to avoid having programs around that have no decimals, you could make the Decimal Required in the same screen. Just be sure to set the format for each Letter accordingly.
Getting back to our Knight, once we enable all this, the backplot changes to be this:
The Red Arrow points to one of many sudden excursions down to the origin of X due to a lack of decimal points…
The Red Arrow on the screen shot points to one of many sudden excursions down to the origin of X due to a lack of decimal points.
Wouldn’t you be glad to have this kind of checking on your GCode? Imagine running a program for the first time on the machine without knowing there were dropped decimal points waiting to trip you up. This is why I always like to run my GCode through a simulator like G-Wizard Editor before I put it on the machine. But here is the best news–using GW Editor, it’s quick and easy to fix the missing decimal points–just run our “Adjust Addresses” Revision with the following settings:
We’re going through every X, Y, and Z, adding zero to the value, and formatting the result back to the GCode…
It may seem a little odd–we’re going through every X, Y, and Z, adding zero to the value, and formatting the result back to the GCode, but it works. We add zero because we aren’t trying to change the value. It’s the “Format Like” step that fixes the problem for us by forcing a decimal point on the gcode.
By the Way, I ran this same code through 3 other simulators, all set up for Haas, and not one of them showed these excursions due to decimal point problems. Extra checking in a simulator is a good thing. G-Wizard even has a soft limit feature to find other kinds of crashes. Not to mention all the other alarms that may not cause a crash but that will waste valuable time at the machine until you can figure out what’s happening.
Like what you read on CNCCookbook?
Join 100,000+ CNC'ers! Get our latest blog posts delivered straight to your email inbox once a week for free. Plus, we’ll give you access to some great CNC reference materials including:
- Our Big List of over 200 CNC Tips and Techniques
- Our Free GCode Programming Basics Course
- And more!
Just enter your name and email address below:
100% Privacy: We will never Spam you!
Bob is responsible for the development and implementation of the popular G-Wizard CNC Software. Bob is also the founder of CNCCookbook, the largest CNC-related blog on the Internet.