cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

ARC not generated in ZX plane by creo conversational PP of TNC426

asifcad
12-Amethyst

ARC not generated in ZX plane by creo conversational PP of TNC426

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

1 ACCEPTED SOLUTION

Accepted Solutions
asifcad
12-Amethyst
(To:KenFarley)

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.....  

View solution in original post

4 REPLIES 4
KenFarley
20-Turquoise
(To:asifcad)

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.

asifcad
12-Amethyst
(To:KenFarley)

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.....  

KenFarley
20-Turquoise
(To:asifcad)

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.

asifcad
12-Amethyst
(To:KenFarley)

 

 

PREVIEW
Respected  KenFarley. really thanks for your appreciation a very good person from somewhere in the world has given me a hint regarding this issue. with the help of his hint and some common sense, I can able to find the solution.
again thanks for your valuable words
 
reards
Asif Fisa
 
Announcements