Community Tip - You can change your system assigned username to something more personal in your community settings. X
looking help about postprocessor ..it is a conversational PP of creo for TNC426 Heidenhain. the problem is ARC not generated in ZX plane by creo conversational PP of TNC426 please check pictures.
in where the area of pp I need to investigate to resolve arc issue which is not on XY plane. right now any arc which is on the XY plane work well but as you saw the 3d trajectory path where the arc is on the ZX plane is not generated properly. I change CIRC_INTERPOLATION to POINTS_ONLY in trajectory sequence and the problem was resolved but I prefer to generate the code which is not on the x,y,z points base.
regards
Solved! Go to Solution.
thanks, a friend for your valuable thoughts and suggestions ..but the good thing is a problem is solved ..the issue was in the post-processor. please check pic to see the culprit.....
Never used one of these machines, almost all the programming I've done is on machines that use G-Code. It looks like you're not informing the machine that the circular paths you are giving it are not on the X-Y plane. So, when presented with Z values in the definition of circles, it instead just does a linear motion from point to point in your path, instead of the arc you desire.
One would hope that a good post-processor would handle generation of the necessary instructions to switch from an X-Y plane for arcs to the X-Z plane, then back to X-Y when done, but it doesn't look like the one you have is doing that.
Do you have any example programs that cut an arc in a non X-Y plane? Is there a simple switch that selects between the planes, like G17 and G18 in G-Code?
No surprise that points only worked, but as you might notice, that type of path is highly dependent on your settings for tolerance - if your tolerance is too big a value, noticeable faceting occurs, etc.
Maybe someone with specific Heidenhain experience can jump in and help. You might also consider going on a quest through the old discussions here to see if any other folks with that type of controller have discussed post-processors and which are best.
thanks, a friend for your valuable thoughts and suggestions ..but the good thing is a problem is solved ..the issue was in the post-processor. please check pic to see the culprit.....
Oh, that's nice. It looks like your post is putting out vectors instead of just C and CC. Many years ago I switched all programming to use vector arc specification rather than "clockwise" and "counterclockwise" specifications. Sometimes mistakes would happen because it would cut the "other half" of the arc. Besides, I like vectors.
Editing FIL code is not simple, especially those POSTF statements. Such a strange language. But, you can do some fancy things with it. Debugging is not easy, either.
Good to see you're attacking this stuff.