Heidenhain radius compensation: Tool radius too large error

[Jaanyaar]

Hi!

I use wear radius compensation. I enter a small DR on the control. Do you have any suggestion to solve the issue?

I use 3 digits for number of decimal places (Metric) . Do you recommend to change it to 4 overall?

[iamcdn79]

What tolerance do you use? I use .001" for toolpath tolerance and make sure my tolerance factor is set to 1 in the Point Distribution. And I never get that error only when the tolerance factor was set to less than 1 would I get that type of error show up.

[Jaanyaar]

Thanks for the tip! Let me ask some questions.

Are you using compensation on 2.5 axis machining only? Or like spiral Constant Z too?

Wear compensation or full radius?

Using look ahead M120 or not?

Do you have experience with M109/110?

[iamcdn79]

-I've never used Constant-Z with Spiral, I always use Corner Pencil with Comp. set to Left

-No M120 or M109/110

How are you setting your tool radius in the controller? Setting it to 0 instead of actual radius of tool always worked in our case. 

ex. When using a 12 mm diameter if we set the the radius to 6 mm we would always get an error saying tool radius too large. When setting it to 0 the toolpath runs without errors.

Also the leads I use are always set to straight not arcs

[M_Hennig]

This may seem like a convoluted way of doing it, but this is the only way I can get it to work for me when using graphics on the control. If I have a 4mm tool, in the basic data area of the tool table, I will have +.1573 then in the DR area under the wear data I will have -.1573, then in the program I will have a small value for the cutter comp wear. There are other ways of doing this, BUT this is the only way I could find that would allow the graphics to work. 

[matthew_metzingerRD8F6]

Good morning.

Might be going off tangentially here, but hope this helps.

I ran a Heidenhain for alot of years, and though the guys at CAMplete, they showed me i could have the following:

R Value in the Tool Table, that the laser gives you (or you put in half the cutting diameter.)

DR Value in the Tool Table, set to 0.0000 (this will be where your CComp adjustments will be made)

Here was the the thing they showed me...

Through the postprocessor, have it output a negative DR value, that is half the programmed cutting diameter, on the TOOL CALL line.

Here is an example (sorry, don't work a Heidenhain anymore, so going by memory...

(4mm cutter to be used, 4mm cutter diameter defined in PowerMill)

TOOL CALL  3  S4500  DR-2.000 (output from PowerMill in the NC Code)

The postprocessor took 1/2 the programmed cutter diameter (4mm /2 = 2.00mm), inverted it to a negative value, and output that value as the DR value, in the NC code, on the TOOLCALL line.

In the tool table, as I said above, R value of TOOL 3 should be 2,00mm (either lasered or manually input)

The DR Value in the Tool Table should begin at zero (which for me is how my lasered set it)

You will adjust your cutter comp as needed here, small values

As I understood it, the way the CAMplete guys explained it to me, the Negative DR Value on the TOOL CALL line is "added" to the R value in the tool table, essentially canceling out the diameter to the controller, and the DR value from the tool table is now "added" or really "subtracted"  from the result, equaling the cutter comp value that is put into the DR Column, and the controller uses this (doesn't sound right the way I said it, but it's something like that)

Before this, we COULD NOT do cutter comp on this high end CNC controller.  After this, man it went SO well.

This was a game changer for me on the Heidenhain,   I shouldn't use the word never, but I never had any weird cutter comp issues after this.

NOTE:  I did not use the graphics function on my Heidenhain, so I don't know how the above will react to that.

My cutter comp issues were during the actual cutting, not in a graphics simulation on the Heidenhain.

If the book I just wrote doesn't help, sorry about that....

[matthew_metzingerRD8F6]

Woops, also forgot this.

Get ready for another short story...

NOTE: the following was being done at a time when we were setting the Tool Table R value MANUALLY to 0.000mm.

Before the story I relayed previously, in the previous post, this was the only way to "sometimes" get cutter comp to work at all, but we still had ALOT of issues making it work, even remotely, and even then we could hardly put -0.002mm cutter comp, and then it would fail, giving the "Tool Radius too large" error on the machine...

Hope this scribble makes sense...

Before any of what I just said happened (in my previous message), we did have to deal with the following (when the machine was brand new)

Deep inside the controller, there was an arc end point tolerance parameter set.

I'll have to look it up, to see what it was on the machine I ran. (2003 Mikron)

From the factory this was set to 0.001mm.  This ended up being WAY too tight (40 millionths of an inch allowable mathematical deviation)

We set this to a more "open" value (can't remember the value, will look it up).

I believe we put something like 0.012mm (0.0005")

This parameter is NOT a tolerance value to let the actual cutter deviate in cutting up to 0.012mm in it's movements.

That was / is a different parameter.

As I understood this, the parameter we changed is only for mathematical calculation deviations that will be allowed during the execution of the toolpath by the controller computer.

Ill have to get my notes at home, and look up the parameter number, and the value we used.

I believe we put something like 0.012mm. 

Anyhow, if any of this helps, well, I hope it does.  If not, I have just wasted a whole lot of bits typing this out...

Oh well.

Matt

[kyle.kershaw]

Hi @matthew_metzingerRD8F6

Your essay is perfect. Loaded with good info. For those in the post hacking world this one is an easy one to implement.

The change is to output DR-tool radius.

Find where the tool call is coming from and edit that command. In this post, the DR+0.0 is from the LOAD_TOOL command and is from a text block (green) and has DL+0.0 in front of it. Edit out the DR+0.0 so the DL+0.0 stands by itself

Drag and Drop (or use the pull-down list) to add the Tool Diameter parameter to the end of that line. Here's where it gets fun.... We need the tool radius and have the tool diameter. Divide by 2 right.

To do that, we need to use an Expression as a Value. This is a little math in the post. Note the Value item is set to Expression and its value is set to %p(Tool Diameter)%/2. The %p( )% stuff reads the value of the parameter with that name and the /2 does just that.

Last is to set the Prefix to DR-. Select <specify> in the Prefix field and enter DR-.

Put it all together and you get 

From a post view it's straightforward. From a machine view the stuff about machine parameters and "not a tolerance" settings sound pretty important.. 

Kyle

[matthew_metzingerRD8F6]

Wow Kyle, very nice work and explanation.

I'm no post writer, but that is great information to have...

Thanks also for the compliments.

In my mind, it's even longer drawn out than what I posted out...

Hopefully this info helps people out...

Thanks again...

[matthew_metzingerRD8F6]

Oh, and Kyle, sorry for it being so long to reply.

That was some work you put into that post.

Hate to think it was just for nothing...

Thanks again...

[matthew_metzingerRD8F6]

The only other thing I could hope for (while hijacking this thread for a minute) would be to be able to run my Fanuc based machines similarly.

If anyone knows what would be needed to make a Fanuc based machine work the same as described previously on a Heidenhain, in that the post puts out half the cutter diameter as a negative value (Variable maybe?) (Probably very similar to what Kyle showed) but the kicker has been for me how to integrate this into how Fanuc based machines do cutter comp.

I have wondered and looked and longed for something like the "TOOL CALL DR-x.xxxx" on a Fanuc based controller.

I brainstormed about outputting half the cutter diameter as some Variable, then read it into the controller, grab the background info that is the cutter information (using variables), doing some silly math in the background, and somehow writing some value somewhere into the Tool Table, so that it worked the same as on a Heidenhain...

Someday...