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.
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.
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
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.
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.
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.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled
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 :
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
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.
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.
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.