arc post mods

[steve f]

Hi,

 

I've modified a post for a customer of mine I'm doing some contract programming for. The machining center he's running is an old 1981 Gemini E control and I'm occasionally running into issues with arc motion under certain conditions. When the start and end point of an arc are < .002" apart and the arc shares nearly the same rotation center point as the preceding arc, the control will perform a complete circle and gouge the part in the process.

 

The short arc motion is generated right out of the NCI so I need to modify the post to either delete one of the small arcs or modify the toolpath entirely.

 

Has anyone run into this before or have any suggestions on the best way to tackle this problem.

 

Any ideas Dave T?

 

Mill 3

MR0304

 

thanks,

 

steve

[foolsh]

it could be you need to change break arc into quadrant in the post

[steve f]

arcoutput is already set to break arc into quadrants. This only occurs when a portion of an arc, like a .5 degree sweep needs, needs to be programmed and the start/end points are very close together.

[steve f]

*bump*

[Camdude®]

you could try setting the "Ltol" variable in the post to a larger number. that would force the post to look for arcs of a certian size or larger before interpolating a G2 or G3 move. you should get linear motion to control the arc. i don't know if this is what you are looking for but i have used this in the past to solve small arc problems before.

[steve f]

thanks camdude, I'll give that a shot.

[Post dept]

Steve,

 

You need to set arccheck to 1 in your post then set your ltol. Arccheck = 1 will convert an arc into line segments if the arc is below the length tolerance (ltol).

 

arccheck : 1 #Check for small arcs

ltol : .002 #Length tolerance

 

Brett

[Post dept]

Guess I'm a little slow...

[JS]

I recently had the same problem out of the blue and recked an expensive part. The problem I had was somehow the arc was drawn .0001 longer than a quadrant so it started cutting a circle. I fixed this by changing arcoutput = 2 = 180deg my control had no problem with this at all, but I think someday I may have the same problem if the arc goes past the 180. I wonder if I cchange the vtol from .0001 to .001 if that will cover this problem a little better.

 

Thanks Joe

[steve f]

Brett and JS, thanks for the responses.

 

I revisited this problem last night and did alot more testing and ran into a wall again.

 

In version 9.1, I found that arccheck would only convert small arcs to lines in the XY plane. My solution was to modify the post so that linarc was set to 1 when any motion occured in the other two planes (XZ and YZ) to break everything up into lines, similar to a 5 axis post.

 

Unfortunately, the file size and slow motion didn't go over well with my customer. After more testing with 9.1 MR0304, I'm now unable to get arccheck to work in any of the three planes.

 

I know the variable definitions changed slightly in 9.1 SP2 and I'm wondering if they have changed again in MR0304.

 

here's what my settings are currently at:

 

arccheck: 1

ltol: .005

 

I've been fighting with this problem off and on since version 9 was released and the work is really starting to pile up (and my customers patience is going down).

 

I can't seem to make this work and wondering if someone can prove me wrong. Any help appreciated!

 

steve

[steve f]

Well, I've narrowed down the issue a little more.

 

In the XZ and YZ planes, the small arcs that result from breakarcs set to 1(quadrants) will not be converted to lines when arccheck is set to 1. Otherwise small arcs between the quadrants are converted to lines.

 

The only deduction I can make is that the post executable applies breakarcs to the toolpath after arccheck in planes other than XY.

 

Steve teh still searching.