Radius Offset and Length Offset

[jim_stoll]

What is the function of these settings? I ended up with a milled hole (created with a Goround) being undersized, so figured that I could compensate for that by setting the Radius Offset value when I select the tool, but it doesn't seem to matter what I set for Radius Offset - the resulting Posted gcode shows no difference. I tried changing the Length Offset, just to see if there was any effect on the gcode from that, and there wasn't any there, either.

Is this a functional setting? Am I doing something wrong, or do I maybe have some type of 'Ignore Tool Compensation' setting set somewhere or such? Am I perhaps missing this capability in my PPR file? Also, if this is a functional setting, what is the unit? (ie, thousands of an inch? percentage of tool radius/diameter? widths of a chinchilla hair?)

Thanks!

[metalworkz]

Hi Jim,
It sounds like it could be a simple mistake in the selection of the direction and or offset check boxes for the GoAround. When you created the tool path for the GoAround there is a dialogue box which has check boxes (Direction)Forward & Reverse, and (Offset) Left, Right, and None. You may have selected the Direction and or Offset inappropriately for the cut. You should be able to correct this situation by visualizing the tool positon relative to the path so that the direction and offset create the toolpath you want. The simulation should show the cutter on the correct side of the path line and the correct direction of travel.
Regards,
Wes

[jim_stoll]

Thanks Wes - I double-checked my selections and toolpath, and all is as I would expect it to be. The undersizing of the hole is not dramatic - nothing near a full or 1/2 cutter width - more on the order of 3-4 hundredths of an inch (dramatic enough to be a problem of course, but not a case of improper offset or direction, I think)

Its possible that my feedrate was too high and I'm getting deflection or even missed steps or such, though I took the feed directly from a well-established feed/speed chart and was pretty conservative in the depth of each pass. I'm going to cut a number of holes at various feedrates to see if that makes a difference, but I'm really wondering if a cutter radius offset wouldn't solve my problem.

I examined the TurboCNC Post that I'm using and there's no mention of any of the G4x commands, so I'm guessing that's why the offset isn't appearing in my generated gcode. (Forgive me if I'm hung up on the offset, but A) it sounds like what I need and B) its something new to me, so I'm kind of like a kid with a new toy or a dog with a bone... :-) I tried using the Mach2 Post, which has G40, G41 and G42 listed in it, but I'm only getting the G43 (length offset) in my generated gcode, not a G41 or G42, despite having both radius and length offset specified in my 'Select Tool' command.


Any further ideas/suggestions??

Thanks Much!!

[metalworkz]

Hi Jim,
I know this is like a work around and I too would like find out about the length and radius offsets but if it works it may be a simple fix:

What is the size of the tool you are using? Is it possible it is undersized and even if not undersized do you think you could define the Tool Diameter as being half the amount of the undersizing of the hole smaller, in order for the program to do the compensation for you(it should offset the smaller tool out to cut the hole size correctly?) What do you think?
Regards,
Wes

[HuFlungDung]

In general terms using full diameter radius compensation, you need the G41 or G42 code and also a call for a "D_" value that corresponds to the register address where you inserted the current tool diameter (or radius) values. The D values are to be installed (by you) as you set up your tools for the program.

If you do not see G41 or G42 in your code, you should probably assume that the generated path is being compensated for the tool radius somehow. The way that you can tell, if you have a way of verifying the coordinates of each entity in the part profile, the toolpath will correspond to the part profile, ie., there will not be an offset, because it is assumed that your controller will be taking care of the offset for whatever tool radius you happen to pick. There are limitations and exceptions, of course, but that is the general idea.

FYI, radius compensation is usually only 'turned on' for a finish path, after the spindle has moved to Z depth, and turned off again (G40) just before the spindle retracts. Because the tool needs to 'move' from 'center tangent' to the path, to 'edge tangent', some allowance must be made when beginning and ending the path, for the tool to get into position. This is most often called a lead in and a lead out. This is an extra bit of code that the cam software must create for you, as you cannot begin with the tool right on the part profile without getting a gouge. If you haven't noticed this going on when creating the toolpath, you maybe should look a little further into the details.

[jim_stoll]

Wes, yes, that sounds like a very do-able 'Plan B'. I first need to try my feedrate tests (several identical holes at different feedrates and depths) to make sure that I'm not facing a cutting issue of some sort. Good point checking the actual size of the cutter, too. I'm using a 3/16" endmill I bought from rom Taig, so I'd just assumed it was accurate - worth checking though! Oddly enough, I've never previously milled out a hole where size was critical, and I've also never previously mic'd any of my finished parts (I'm fairly new to all this stuff, and I'm just a Dude in a Basement... :-), so who knows, I may have been having this type of problem all along and never realized it.

[jim_stoll]

HuFlung - thanks for the further explanation on on the cutter compensation. When I initially didn't see a G41 or G42 in my generated gcode, I assumed that the offsets must be included in the generated G02 or G03 commands for the circle. But I ran several variations on the same hole (each variation with a different radius compensation value), and the generated code in each case was identical, so it doesn't appear that the compensation is being built into the cutting path. Now, I'm using values like 0, 1, 10, 100 and 1000 for the radius offset attempts - just gross-level values to sort of 'poke it and see if it moves', but I have no idea what the units are for radius offset, so its possible that my values are not useable and are thus being ignored. What is the unit for the radius compensation, and what kind of value should it realistically be?

I like Wes' idea of oversizing the endmill in the tool definition as a work-around, though I'd really rather get it to work 'correctly', be that with or without an actual cutter compensation. I have to do some more testing to try to get a better handle on the actual source of the discrepancy though.

I originally created the hole via a Goround with no approach or runoff. After reading your post, I regenerated the gcode as a Goround with 'Arc' Approach and Runoff , and as a Pocket (which seems to have its own Approach/Runoff built in). While the gcode generated for each was a little different, each consisted of the same 3 central G03 commands, which looks to me like the same basic circular path is being cut - just with variations in the approach and runoff. I also tried ticking and unticking the 'Use CRC' checkbox in the Pocket operation (sounded promising!), but that had no effect on the generated gcode either way.

[HuFlungDung]

If you have found the D register for tool radius in your Mach controller (which I know nothing about, btw), you would typically enter the nominal tool radius (or diameter depending on what Mach expects you to use).

You may have to wait for someone to come along who uses Dolphin, to figure out just how you are supposed to get it to post a machine radius compensation correctly.

Here is a small program you can do a test run with. It is based on a 2" square, with 1/8" radius corners. This is how it could look, although the start point and end point are totally up to the user to pick, I took no pains about where I began.

T1 M06 ( 4FL SMT 1/4" CARB REG LEN .75")
G90 G80 G40
G54
/G00 X0 Y0
G43 H1
S5000 M03
M08
G00 X1.675 Y0.9042 Z1.
X1.675 Y0.9042 Z0.05
G01 S5000 X1.675 Y0.9042 Z-0.05 F12.
G41 D1 X1.775 Y0.7792 F24.
G03 X2. Y1.0042 I0. J0.225
G01 X2. Y1.875
G03 X1.875 Y2. I-0.125 J0.
G01 X0.125 Y2.
G03 X0. Y1.875 I0. J-0.125
G01 X0. Y0.125
G03 X0.125 Y0. I0.125 J0.
G01 X1.875 Y0.
G03 X2. Y0.125 I0. J0.125
G01 X2. Y1.0042
G03 X1.775 Y1.2292 I-0.225 J0.
G01 G40 X1.675 Y1.1042 Z-0.05
G00 X1.675 Y1.1042 Z1.
M09
M01
M5
G00 G91 G28 Z0
G00 G90 G53 X-20. Y0.
T1 M06
M30

[jim_stoll]

Cool - thanks for the sample HuFlung! I'll try that out and play with it a bit and learn some things!

I'm not actually using Mach as my driver program. I use EMC, but for whatever reason, there doesn't seem to be an EMC post for Dolphin. I've been using the TurboCNC Post - basically because its simple and I can pretty much understand it, plus, EMC finds the gcode generated by the TurboCNC Post to be palatable - it gags on some gcode generated by the Mach2 post. The Mach2 post seems to have some features/capabilities that the TurboCNC post is lacking though, and I suspect that I'm going to end up with a hybrid of the two before all is said and done. There have GOT to be folks out there using Dolphin to generate gcode for EMC-controlled machines, but darned if I can find an EMC-specific post for Dolphin!

Thanks Again!

[Chad_Clark]

Tool length compensation is the easy one ...
When a tool change occurs on an NC milling machine, (manually or automatically), it is almost guaranteed that the new tool and the previous tool will have different lengths. This means that the Z axis must move to a different position for each tool in order to place the business end of the tool at particular Z value relative to the Z datum - usually the top surface of the job.

There are ways round this -

the programmer can compensate for the length of each tool in the NC program. This is impractical because it means the programmer must know the length of each tool in advance.
The operator can reset the controller with each tool change. This involves manually position the Z axis so that the new tool just touches the Z datum surface, and then he "zeroes" the Z axis. This effectively means that all tools are now the same length and simplifies the programmers job because he no longer has to worry about tool length - In fact he can ignore it. This scheme works fine for manual tool changes but if the machine has an automatic tool changer it is no good. The operator cannot zero the Z axis at every tool change.
With automatic tool changes, the operator must "zero" every tool before the NC program starts. The controller records the relative length of each tool in a "Tool length compensation register" typically an "H" word in the NC program. The controller has enough of these "H" words to store the length of every tool. Typically the length of tool no 1 is stored in tool length register no 1 (H01) and so on.
When a controller is using tool length compensation the tool change sequence looks something like this ...

G00 Zzsafpos - retract to a safe value in Z at rapid
G00 G49 Ztoolchange - cancel tool length compensation and retract to the Z tool change position
TnnM06 - select tool number nn
G00 G44 Zsafpos Hnn - descend to the Z safe position and switch on tool compensation using register nn


Note : the Z safpos position is relative to the workpiece, the Z toolchange position is an absolute value in machine tool coordinates.

So the answer to your question is, the tool length compenstion (offset) value is usually the same as the tool number.

Tool radius compensation is slightly more tricky. Ideally the programmer wants to program the finished part coordinates and have someone or something else worry about where the tool needs to be i.e. to compensate for the tool radius.

When Noah was building the arc, the programmer had no choice but to get his abacus out and calculate the toolpath manually. In other words the programmer dealt with cutter radius compensation.

The came Computer Aided Machining (or Manufacturing) and it was a lifetimes salary to buy one seat, so every one but Boeing, ignored it. The controller manufacturers cam up with a solution - tell the controller the radius of the tool and let it work out the toolpath given the finished part coordinates - Part Surface Coordinate programming became a reality. The programmer ignored the size of the tool and programmed the finished part. The controller used the tool radius stored in a "Tool radius compensation (or offset)" register typically a "D" word to compensate for the radius of the tool. Under this scheme the radius offset register usually shares the same value as the tool number.

This scheme does have its drawbacks - the programmer may not program any internal arc smaller that the size of the tool in use - so if the operator breaks it and the only tool available is larger, the program is a write off.

Most (70's and 80's) controllers that supported this style of programming had primitive computers and were not actually very good at dealing with internal corners and small cutouts (i.e. smaller than the tool) resulting in a lot of scrap, later controllers were much better but tended to be more expensive.

Now that computers are two a penny, personal cadcam systems mean that the desktop computer can deal with cutter radius compensation effectively and cheaply. The programmer - with the aid of the CAM system program the toolpath not the finished par geometry. THis means that the NC program is written for a specific size tool and will cut undersize or oversize if any different size tool is used. To get round this the tool radius compensation features on the controller are now used to compensate for small differences in tool size - not to compensate for the radius. The most common use for cutter radius compensation is to deal with tools cutting undersize due to wear and the resharpening process (or for tool push off i.e. bending of the tool shank).

When you program cutter radius compensation / tool length compensation, you are actually referring to registers on the controller, these registers must have meaning full data in them, and the post-processor must pass through the relevant info to the NC program. (Not all posts do this). If the post is outputting the necessary codes you will typically see something like ...

G00 X Y - move to start position
G00 Z feedchage
G01 Z zdepth - descend to depth
G01 G41 X Y Dnn ... - move to start of contour - switching on cutter radius compensation on the way.

Cutter radius compensation is handled by G40, G41, G42 and a cutter radius compensation register "D"

In the example below - which is basically the correct thing to do - the NC program wont change. You basically need to decide which register to use and reference that in PartMaster (often it is the same as the tool number) - then and this is the critical bit - you need to enter a value into the register - on the controller - that will compensate for the tool cutting under size of oversize.

Lets say you program a 3" hole using a 1" cutter. PartMaster will actually output an arc move with 2" radius.
When you measure the hole it comes out at 2.950, You have two choices, either you re-program it using a 3.025 tool or you use the cutter radius compensation register and enter a value of 0.025 (half the error) and run the program again. The first technique should be OK, the second requires that the program (i.e. the post-processor) is set up to deal with cutter radius compensation.

Useful links ...
http://www.desktopcnc.com/articles/concept4.htm
http://www.isd.mel.nist.gov/personne...74NGC_38a.html
http://www.shoptalkmag.com/index.cfm...rs=0&artid=155

[Chad_Clark]

Cool - thanks for the sample HuFlung! I'll try that out and play with it a bit and learn some things!

I'm not actually using Mach as my driver program. I use EMC, but for whatever reason, there doesn't seem to be an EMC post for Dolphin. I've been using the TurboCNC Post - basically because its simple and I can pretty much understand it, plus, EMC finds the gcode generated by the TurboCNC Post to be palatable - it gags on some gcode generated by the Mach2 post. The Mach2 post seems to have some features/capabilities that the TurboCNC post is lacking though, and I suspect that I'm going to end up with a hybrid of the two before all is said and done. There have GOT to be folks out there using Dolphin to generate gcode for EMC-controlled machines, but darned if I can find an EMC-specific post for Dolphin!

Thanks Again!

Is the customized post we made for you working correctly?

[jim_stoll]

Wow, Thanks Chad - that was a fantastic explanation for a layman like myself! I now see why my radius and length offset values weren't having any effect on the gcode, too. <:-) I'll have to check EMC to see if it supports these compensation registers - I'm guessing it must, but don't know for sure.

It had previously been suggested to me, and it may be the simplest approach, that I simply fudge the cutter size in the tool definition in DCAD - it sounds like the offset register is just another approach to the same end. What I need to experiment with is whether I get the same effective size difference under all conditions or if its more prevalent when cutting circles than lines, holes vs outside countours, climb vs conventional, etc. I've cut a number of parts previously, but this was the first time that fit on a particular feature was critical, so I may have had this happening all along and just not realized it.

BTW, the modified TurboCNC Post that you did for me has been working fine - no more issues with the arcs not mating up - Thanks!

It would be nice to add the G40, G41 and G42 capabilities to it. The Mach2 Post will output a G4x with the H register value, but not the D register value. I was going to try to copy & paste the relevant sections of the Mach2 Post to the TurboCNC Post, but given that the Mach2 output doesn't include the D register value, it may need a little further looking at by you.

Here is the gcode produced by the original, unmodified Mach2 Post for a tool selection that has the radius and length offset both set to 3 - note that a G43 is generated that provides an H value, but no D value is output anywhere:

O100
N7G00G20G17G90G40G49G80
N8Z0.25
N9G49
N10T3M06 ( End Mill )
N11G00G43Z0.25H3
N12S1000M03
N13G94
N14M08
N15S1000
N16X0.9063Y0.5
N17Z0.1181
N18G01Z-0.25F0.163
N19G03X0.5Y0.9063I0.5J0.5
N20X0.0938Y0.5I0.5J0.5
N21X0.5Y0.0938I0.5J0.5
N22X0.9063Y0.5I0.5J0.5
N23G00Z0.25
N24M09
N25M30


Here is the output of the latest TurboCNC Post that you sent me for the same program - no G4x code of any variety is produced:

G90
G20
G00 X0.0 Y0.0 Z0.25
G00
M05
M06 T03 ( End Mill )
M03 S1000
M07
M03 S1000
G00 X0.9063 Y0.5
G00 Z0.1181
G01 Z-0.25 F0.163
G03 X0.5 Y0.9063 I-0.4063 J0.0
G03 X0.0938 Y0.5 I0.0 J-0.4063
G03 X0.5 Y0.0938 I0.4063 J-0.0
G03 X0.9063 Y0.5 I0.0 J0.4063
G00 Z0.25
M02

Thanks Again for the help!!