cancel
Showing results for 
Search instead for 
Did you mean: 

Tool radius too large (Postprocessor / Heidenhain / contact counter)

Pioneer
Pioneer

 Hello,

 

we often get with Cavity_Mill process and Heidenhain the error message "Tool radius too large".  Our solution in the moment is, that the worker in front of the machine put a line "M120 LA5" or something like that. But i think that can not be. In CSE Machine code simulation everything is fine. Our Postbuilder mean that this is a problem of Heidenhain, but i think this is a arithmetical problem from the post. Have somebody an idea of the settings inside the CSE and post what we need to change that its work ? I saw in a documentation of Heidenhain (CAD_CAM_CNC_Webinar.pdf) that they recommend that post output have 4 decimal place,circles with CC/C – CT – CR output. But this doesn also bring us the solution. So i want to know - whats your solution of that problem and what settings you have make in the CSE/PP to solve the problem. We got this problem with contact counter and 1 or 2 time i got this problem also without contact counter.

 

thx

NC Programmer
NX 8.5.3.3
28 REPLIES

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Esteemed Contributor
Esteemed Contributor

This is a general problem with the Heidenhain control, you need M120 LA3 at least to have cutter radius compensation with contact contour working.

 

The problem is that the control is too restrictive, when the radius to machine is equal or less than the cutter radius.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Siemens Phenom Siemens Phenom
Siemens Phenom

Hello

 

one comment to simulation CSE only. Today the OOTB CCF doesn't include M120 or look ahead LA option, but I am pretty sure that can be customized.

 

Thomas Schulz
Siemens PLM
Manufacturing Engineering Software

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Pioneer
Pioneer

Hello Sefan,

 

i am not shure, that is the solution to put every time M120 inside. Last time i make a phonecall to Heidenhain and ask i can let put general M120 inside my PP. He say thats not a so good idea. I don know exactly the reason but its not advisable.

 

One time i got the problem also without cutter compensation (R0). I saw a great function in the older Heidenhain iTNC530. tHere you have the chance to reverse your RL ouptput in R0 output. So i take the problem program, put by hand M120 inside and let it reverse calculate. After that i get the middleway output. It was different from my NX output (with R0) but i think that must be the same.

NC Programmer
NX 8.5.3.3

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Pioneer
Pioneer

Hello Tom,

 

I think if I get a correct PP counter I don t need to customize M120 in the CSE.

 

 

NC Programmer
NX 8.5.3.3

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Experimenter
Experimenter
Hello, I was asking GTAC for this problem and report it as IR and final answer was: "Sorry I can't give you a solution for this." I am writing this, because NX has not official solution and is beneficial if the problem is reported more often for supporting solution to this problem. Summary of our communication is: 1) question: we have often trouble with tool path generated with "Cutter Compensation". Our machines stop machining with error "Tool radius too large". This situation come unexpectedly and only on machine, is not seen in NX. We try to solve this problem by changing some "Cutting Parameters" "Cut Levels" etc., but this helps only in few cases. So we have to use "M120" function directly in program, but this is not effective in every case. From other CAM, which we use, is this type of error too, but very rarely compared to NX. answer: The most obvious is to use a tool with a smaller radius(diameter) as the error is probably caused by a too large tool trying to machine a too small corner. I've seen that Heidenhain can be a little bit tricky using cutter compensation. Some suggestions have been to make the following changes in the postprocessor: - change the circular output to quadrant - include *M120 LA3* with the RL and RR words 2) question: - I am not sure that could help if we use circular output to quadrant, because it splits path to more segments and makes more connections and maybe potentials problems. - function M120, for example when it is used in engage for helical hole milling it could skip some part of path and helical is reduced to simply plunge, directly to its end. I prefer using it only at necessary cases, not generally. I think that it is problem with accuracy of generated paths, maybe accuracy that represent used model or... How it works with other users? answer: I have searched our database on the error message "Tool radius too large" without getting any hit at all. When I searched on M120, I found the information I mentioned in my previous mail. I have talked with an experienced colleague about this and his thought was, as you suggested, a problem with the accuracy in calculation. His experience is that this is not only for cutter compensation but general for circular movements. NX is using a very high accuracy in the calculation which sometimes can cause rounding differences on the last decimal. The most important is that the Heidenhain controller and the NX postprocessor are using the same way of calculation, because this can also be changed in the controller. Change the number of decimals (up or down depending of the value you have today) used for calculation of X & Y (maybe also Z) in Post Builder and postprocess. If you compare the 2 output files and there is a difference, test it in the machine. Continue the change until the machine will accept the tool path. 3) question: I have tested your recommendation. I changed number of decimals for X Y (Z) and parameter "mom_kin_machine_resolution" and I see, that generated coordinates in program has been realy changed, but machine did not accept the tool path still. I continued with changing Intol-Outtol in "Cutting Parameters/Stock/Tolerance" and set value to 0.3 ; 0.03 ; 0.003 ; 0.001 ; 0.0001. Except value 0.003 was this setting working, but only with one example. With other examples did not work nothing. Now after making of many combinations I did not find any setting that could be generally applied and solve functionality for path with correction. All our machines are set up basically to use (display) 4 decimal places and from our other CAMs (Surfcam, SolidCAM, WorkNC) we generate 3 decimal places, and this is sufficient and is working on the same machines as PGM from NX. answer: According to our expert, the only additional thing to do is to in the postprocessor build some kind of check to see if a condition wich will cause the error will occur. Like what you have in the controlller when using M120. This is something that a Siemens Professional Service consultant might be able to help you with. Sorry I can't give you a solution for this.

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Esteemed Contributor
Esteemed Contributor

We had some issues with Okumas, typically when the tool has a "5" in the "next" decimal place (beyond what is output).  I ended up writing code to check for  .xxxx5 (for 4 decimal places) and if so, added .00001 (so it rounds up).  Seemed to fix *most* cases.

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled


Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Pioneer
Pioneer

@jan:

thx for your great answer. I can believe that we 2 only have that problem. As I read your post, I must laugh.

I have think I have write that post. Everything equal. I also try many differents options and like you I get never a program with 100% guarantee. In the moment we make like that :

  1. Create program
  2. PP and simulate in CSE (with code not CLdata)
  3. walk to a Heidenhain Programmingstation and check again
  4. after there is run correct I send to machine

As you see we also have big problems and a long way we get a working programm.

 

If somebody can read german, here a nice Webinar from Heidenhain

xww.klartext-portal.de/uploads/smc/58f37266baa62fe9ff95972d7f89e841500ab657.pdf

On side 14 they recommend 4digits in PP output (optional 5)

We have also try this - bring nothing.

Maybe 1 time we get a solution from the Siemens side. I hope many more users read this post a wrrite a request. The biggest thing what make me angry is, that i didn see the problem in NX before I put the final programm out to the machine. But thanks to all for there experience.

NC Programmer
NX 8.5.3.3

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Siemens Valued Contributor Siemens Valued Contributor
Siemens Valued Contributor

Heidenhain has a demo version of their controller software called "programming station", it will only read 100 lines of code, but it should be helpfull in debugging your output, follow the link below to find the one that suits your needs, BTW I found that using 5 digits to the right of the decimal point worked best.

 

 

 

http://www.heidenhain.com/en_US/documentation-information/software/download-area/

 

Good Luck

 

Frank Bartucci
NX CAM COE

Re: Tool radius too large (Postprocessor / Heidenhain / contact counter)

Pioneer
Pioneer

Hello,

 

1) ... BTW I found that using 5 digits (5 digits are optional as i write before)

2) ... Heidenhain has a demo version of their controller software  (we have a full version)

 

:-)

 

What I like is to see the errors in th CSE and not in the "programmin station"

 

But what I try next is to tell my Postprogrammer to let out 5 digets and try ken solution ..."I ended up writing code to check for  .xxxx5 (for 4 decimal places) and if so, added .00001 (so it rounds up).  Seemed to fix *most* cases."

 

For me is that not a clear solution from Siemens side.

 

NC Programmer
NX 8.5.3.3

Learn online





Solution Information