Irregular circles with Fanuc 0-mc

[Logan_]

I have a glass cutting machine with a fanuc 0-mc controller. The problem I have is when cutting circles. The circles consistently come out like an ellipse, with the major an minor axis in always the same spot. The major axis is about 28 degrees above the machine's x-axis. The axis' are only 0.015" different but I would like to reduce that to 0.006".
I've read up on this to discover people with this problem have x-y square issues. I have cut large squares to find the axis' are off by maybe 0.1 degrees. The diagonals of the squares I measuring have never been off more than 0.002".
The consistency of this machine is very good and the placement repeatability is phenomenal. I don't think backlash plays any role in this problem. Is the circular interpolation created by the controller whack? Is this a common problem? Am I expecting too much accuracy for this operation? Is there any compensation parameters in the controller other than backlash?

Thanks, Logan

[underthetire]

Is the egg shape out in the 45deg quadrants or out 90 degrees to the axis. I'm not sure i'm following your description. 0 controls on mills can handle .0001 circularity all day long, if the iron can. Not a control issue most likely, probable a mechanical problem or drive tuning. Does this machine have the Fanuc red cap AC servo motors on it, or some other system? There are probably 150 different parameters for motor tuning with Red Cap motors, if something other than fanuc motors all bets are off.

[Logan_]

Essentially it is creating a circle and the low side is 0.015" less than the high side. The part I can't figure out is why the high and low diameters are happening in the same spot every time.

Yes it has redcap motors. I'm kind of looking for a scaling parameter. Essentially I g-code in a 3.55 circle and get a 3.2 circle as finished part. I was wondering if i could change a scaling factor to compensate.

[yoshi900]

I had ran into a similar problem on my mill. I solved it by changing the cam system to post circle at max of 90deg sweep instead of 180deg.
can you post your code? hard to explain in word, but let me see if your situation is same as mine.

[sinha_nsit]

Never use radius method for 180 deg arcs. It is not accurate when angle is close to 180 degree. Use center method instead.

[angelw]

Originally Posted by sinha_nsit Never use radius method for 180 deg arcs. It is not accurate when angle is close to 180 degree. Use center method instead.

Hi Sinha,
As you know, this aspect of using R has been discussed at length in another thread, with no conclusion as to why there may be an error when using R other than the physical result on the machine of the OP.

As you would have gleaned from my previous posts, I'm not a fan of using R in circular interpolation programming, but nonetheless I find it difficult to swallow that using R would result in inaccuracy provided the start and end coordinates of the arc were accurately calculated.

Its true that using R will simple give you the best fit arc if the end point is not on the desired circular trajectory of an arc of a fixed center. The control does this by shifting the center to make it pass through the start and end point if the end point is not where it should be, provided that its geometrically possible to do so. Whereas when using I,J and K to identify the arc center relative to the start point, an alarm will result (depending on parameter setting) if the end point is not on the proposed trajectory.

Most control systems generate arcs by using a Start Angle, a Traversing Through Angle, and a Radius; this information being calculated by an interpreter using the G code passed to it. So in the case of when R is used, the interpreter would have to calculate the arc center, as opposed to the center being virtually fixed when I,J and K are used in the G code program.

Why I find it difficult to accept that using R would be any less accurate than I,J and K, is that the mathematics involved in calculating the arc center based on two points and a radius is by no means difficult, and I'm sure that popular control engineers would have the mental clout to design a routine that would accurately deal with arcs based on two points and a radius.

Of all the arcs to calculate a center for, a 180 degree arc having its start and end point on a line parallel to an axis is the simplest, being the average of the two X and two Y or Z coordinates. Accordingly, why should it be that 180deg arcs be inaccurately generated when programmed using R format?

Following is one method of calculating the arc center given two points and a radius.

Regards,

Bill


In the following math:
r = the arc radius
X1,Y1 = the start point
X2,Y2 = the end point

If the arc is 180 deg, only Step 2 is required.

Step 1
Get distance between 1st and 2nd points
q = Sqr((X2 - X1) ^ 2 + (Y2 - Y1) ^ 2)

Step 2
Find mid point of q (X3,Y3)
X3 = (X1 + X2) / 2
Y3 = (Y1 + Y2) / 2

Step 3
Find center point of arc
X = X3 + Sqr(r ^ 2 - (q / 2) ^ 2) * (Y1 - Y2) / q
Y = Y3 + Sqr(r ^ 2 - (q / 2) ^ 2) * (X2 - X1) / q

X = X3 - Sqr(r ^ 2 - (q / 2) ^ 2) * (Y1 - Y2) / q
Y = Y3 - Sqr(r ^ 2 - (q / 2) ^ 2) * (X2 - X1) / q

[Superman]

Just a comment on the side
We had a retro-fitted machine that generated elipses across a diagonal line instead of circles.

Turned out the retro ppl used a grub screw into a keyslot to secure the leadscrew to the servo motor.
so check the mechanics as well

[tc429]

I'd doublecheck that linear acc/dec for feed parameter is ZERO, have seen it screw up interpolation before if anything is in there.

if its a analog servo control, program a 45 and watch following error at dgn 800/801- they must match (or be exactly half or double if servo sizes are different) or arcs will become polygons. the pots on the old drives are gain/offset/tach in that order from top to bottom or left to right depending on the card, turn auto drift comp in parameter 0 or 1 off, set drift comps to zero(around param 540 if I recall), adjust offset to zero following error at rest, run the 45 program and adjust tach pots to match- if counterbalanced axis involved, may have to fudge the offset a little to get it equal up/down, then rematch the tachs- do this at your actual cutting feedrate to get best possible roundness...had this issue long ago on horizontal mills, still see it once in a while, but the old analog stuff is getting scarce anymore around here.

EDIT-
sorry, just noticed the thread said 0M-C, so forget all the analog stuff
rereading, gotta wonder if lead error comps have ever been set- is this based on a metal cutting machine, or more like a flamecutter? just wondered as Ive seen some with simple belt/rack-pinion or even allthread screw drives instead of ballscrews

[yoshi900]

I don't know the math behind it. But it's very easy to see why R method and 180deg arc is bad with this example.

draw an arc in your cad program with the
start of the arc at x1.0 y0
end of the arc at x-.9999 y0
and radius of 1.0

in Autocad, the arc generated had the center off by 0.010, and the midpoint of the arc ended up at x0.0 y.9900

do it twice and you have a circle that's 0.0001 off in the x direction and .01 off in the y direction.

so i guess you can say it's a error cause by rounding off at the 4th digit after the decimal point. and it seems like it cause an error by a factor of 100.

[angelw]

Originally Posted by yoshi900 I don't know the math behind it. But it's very easy to see why R method and 180deg arc is bad with this example. draw an arc in your cad program with the start of the arc at x1.0 y0 end of the arc at x-.9999 y0 and radius of 1.0 in Autocad, the arc generated had the center off by 0.010, and the midpoint of the arc ended up at x0.0 y.9900 do it twice and you have a circle that's 0.0001 off in the x direction and .01 off in the y direction. so i guess you can say it's a error cause by rounding off at the 4th digit after the decimal point. and it seems like it cause an error by a factor of 100.

In my last post, I qualified the use of R by stating that if the Start and End points are calculated correctly, why would the result be inaccurate. In the example you've given your end point has been calculated inaccurately for a radius of 1.0; your end point should have been X-1.0 y0.0.

Regards,

Bill

[yoshi900]

Originally Posted by angelw In my last post, I qualified the use of R by stating that if the Start and End points are calculated correctly, why would the result be inaccurate. In the example you've given your end point has been calculated inaccurately for a radius of 1.0; your end point should have been X-1.0 y0.0. Regards, Bill

Guess I didn't explain it clearly enough. My point was that if you had to round off even the the 4th digit after the decimal point, you can end up with a circle that's almost .010".

So lets say you draw a circle R1.0, split it in half at some random angle (i.e. 10.53 deg). you will have some start point like (i.e.. x0.984736,y.1234959) so your start and end point will have to be rounded off to the 4th digit. and that's where the problem comes.

Hope I made this more clear with this more confusing example.

[angelw]

Originally Posted by yoshi900 Guess I didn't explain it clearly enough. My point was that if you had to round off even the the 4th digit after the decimal point, you can end up with a circle that's almost .010". So lets say you draw a circle R1.0, split it in half at some random angle (i.e. 10.53 deg). you will have some start point like (i.e.. x0.984736,y.1234959) so your start and end point will have to be rounded off to the 4th digit. and that's where the problem comes. Hope I made this more clear with this more confusing example.

I know exactly where you're coming from, but I think you'll find that its software relative. The attached picture is of exactly what you stated in your last example. Circle of 1.0 radius, split in half at a random angle, and the start and end points used to draw another circle using the circle through 2 point with a radius method. The result, as you can see is a circle with a center at X0 Y0; exactly the same as the original. The only difference being is that it was done using the CAD/CAM system that I and a colleague developed.

My point is, that there is no need for there to be the inaccuracy you're talking about. Back just before MS Windows was first introduced, I developed a CAD system that was streets ahead of Autocam at the time. However, writing it into a Windows app, was far too time consuming for a one man band and so I dropped further development of it. I still use this same CAD system on a DOS machine, and for most CNC program applications it still beats Autocam hands down.

Regards,

Bill