Fanuc controls, partial arcs are cutting as full circles

[LockNut]

Here we go again and still stumped by this. Please let me explain as well as I can. Another customer has called complaining that a small arc in a really dense program is actually deviating and cutting a full circle. I had another customer call about the same thing about a year ago. This latest event happened on a Fanuc 21i and the previous case was on a Fanuc Oi control. I had this happen to me way back in the 90's and scrapped 2 $30,000 mold cores. One was an 11M Fanuc and the other was a brand new 16i Fanuc.

In all cases arc fitting was used. In all cases verify was used and back plotting was used. In the most recent 2 cases I was not able to duplicate it on our showroom machines with the customers program. It did not matter whether I's and J's were used or whether R's were used to define arc center. It's not the CAM program because in all cases a different CAM program was used. Mastercam in the last two cases and Unigraphics in the others. Like I said, verify and back plotting did not show anything. In the year ago instance the customer marked the offending arc in his program. It had a radius of 92" and an arc length of only .0002". I still could not duplicate this on our machines with the same control.

The latest customer stated that this same program ran fine on a machine that used G05.1 but the offending control did not have any look ahead. The only way I fixed it was NOT to use arcs but that is only a work around and we still have no cause.

This has stumped me for years and is bugging the crap out of me. Fanuc claims no knowledge of this. Has anyone seen this scenario, ever? I would like to pin this down one way or another despite what the news may be, god or bad.

Thanks,
Paul

 

[DMF_TomB]

Here we go again and still stumped by this. Please let me explain as well as I can. Another customer has called complaining that a small arc in a really dense program is actually deviating and cutting a full circle. I had another customer call about the same thing about a year ago. This latest event happened on a Fanuc 21i and the previous case was on a Fanuc Oi control. I had this happen to me way back in the 90's and scrapped 2 $30,000 mold cores. One was an 11M Fanuc and the other was a brand new 16i Fanuc.

In all cases arc fitting was used. In all cases verify was used and back plotting was used. In the most recent 2 cases I was not able to duplicate it on our showroom machines with the customers program. It did not matter whether I's and J's were used or whether R's were used to define arc center. It's not the CAM program because in all cases a different CAM program was used. Mastercam in the last two cases and Unigraphics in the others. Like I said, verify and back plotting did not show anything. In the year ago instance the customer marked the offending arc in his program. It had a radius of 92" and an arc length of only .0002". I still could not duplicate this on our machines with the same control.

The latest customer stated that this same program ran fine on a machine that used G05.1 but the offending control did not have any look ahead. The only way I fixed it was NOT to use arcs but that is only a work around and we still have no cause.

This has stumped me for years and is bugging the crap out of me. Fanuc claims no knowledge of this. Has anyone seen this scenario, ever? I would like to pin this down one way or another despite what the news may be, god or bad.

Thanks,
Paul

.
many cnc need a circle milled as 4 separate arcs. when they cross quadrant 0, 90, 180, 270 degrees problems happen. often post processor can be configured to give more arcs that do not cross quadrants. very much depends on cnc control

 

[Jashley73]

Is cutter comp on? I've seen in the past where a nearby offending move will change the cutter-path as the machine is pre-positioning the tool to stay on path for the next move. That tip/thought probably won't help, but it's the only thing that jumps to mind...

It had a radius of 92" and an arc length of only .0002"

So what happened here? Did it try to cut a full circle with a 92" radius?

I've also had on lathes with 0i-TD controls, where I've had to re-write the code because it simply would not run the code generating the short arcs. I had one particular program that would run on an Okuma and Mazak control, but would not run on the Fanuc. On that particular program, I had to loosen up #3410 arc-tolerance - even though the math was correct - in order for it to run. Another similar program was running fine for a few cycles, then all of the sudden would not run without generating the PS alarm (PS0041) relating to arc-tolerance.

I don't know why, but I've definitely seen a few cases where the Fanuc control won't interpolate small arc moves...

 

[dodgin]

Here we go again and still stumped by this. Please let me explain as well as I can. Another customer has called complaining that a small arc in a really dense program is actually deviating and cutting a full circle. I had another customer call about the same thing about a year ago. This latest event happened on a Fanuc 21i and the previous case was on a Fanuc Oi control. I had this happen to me way back in the 90's and scrapped 2 $30,000 mold cores. One was an 11M Fanuc and the other was a brand new 16i Fanuc.

In all cases arc fitting was used. In all cases verify was used and back plotting was used. In the most recent 2 cases I was not able to duplicate it on our showroom machines with the customers program. It did not matter whether I's and J's were used or whether R's were used to define arc center. It's not the CAM program because in all cases a different CAM program was used. Mastercam in the last two cases and Unigraphics in the others. Like I said, verify and back plotting did not show anything. In the year ago instance the customer marked the offending arc in his program. It had a radius of 92" and an arc length of only .0002". I still could not duplicate this on our machines with the same control.

The latest customer stated that this same program ran fine on a machine that used G05.1 but the offending control did not have any look ahead. The only way I fixed it was NOT to use arcs but that is only a work around and we still have no cause.

This has stumped me for years and is bugging the crap out of me. Fanuc claims no knowledge of this. Has anyone seen this scenario, ever? I would like to pin this down one way or another despite what the news may be, god or bad.

Thanks,
Paul

Man, something similar happened on a program I run for a local customer every few months or so, simple lifting eyes welded onto bigger component - all the program is is two circles, one big and one small. Anyways, plug the program into the Haas and out comes a good part, plug the program into the small mill with Fanuc Oi and out come to football shaped holes instead of circles. What happened with us was the parameters had been accidentally wiped out by a more inexperienced operator, so we had to plug them back in first from a printout a mile long of the parameter record from about 7 years ago. After that didn't work we found a more updated backup of the parameters on the shop computer and plugged those in. I'll sift through what we found but it ended up being some parameter in the 3000 or 3600 range that fixed the problem. Not quite your problem on not quite your controller, but it seems close enough to make mention.

 

[LockNut]

This isn't a matter of breaking arcs into quadrants. This has been done. But since an arc has been fit into what could be a line segment, there may only be a half degree or less of rotation along that arc, this method has no bearing on the results. My answer is to not use G02/G03 at all but that does not sit well with people that have to deal with this. Bottom line is this should NOT be happening.

Paul

 

[DMF_TomB]

radius of 92" ?? maybe control has a size limit and a diameter of 184" is 3 digits 123.1234 to left of period is causing problems ?

 

[LockNut]

Is cutter comp on? I've seen in the past where a nearby offending move will change the cutter-path as the machine is pre-positioning the tool to stay on path for the next move. That tip/thought probably won't help, but it's the only thing that jumps to mind...


So what happened here? Did it try to cut a full circle with a 92" radius?

I've also had on lathes with 0i-TD controls, where I've had to re-write the code because it simply would not run the code generating the short arcs. I had one particular program that would run on an Okuma and Mazak control, but would not run on the Fanuc. On that particular program, I had to loosen up #3410 arc-tolerance - even though the math was correct - in order for it to run. Another similar program was running fine for a few cycles, then all of the sudden would not run without generating the PS alarm (PS0041) relating to arc-tolerance.

I don't know why, but I've definitely seen a few cases where the Fanuc control won't interpolate small arc moves...

Yes, that is exactly what it did, and scrapped the part. Problem is, it's totally random. You can't foresee this problem because the actual code is good. The way the control interprets it is not.

Paul

 

[Jashley73]

Using G41/G42?

 

[yardbird]

"Here we go again and still stumped by this" I take it you've posted about this problem sometime in the past here on PM? Maybe put up a link if so?

Very Interesting!!

Brent

 

[LockNut]

Using G41/G42?

Nope, this is a Mastercam 2D High Speed roughing routine.

 

[LockNut]

"Here we go again and still stumped by this" I take it you've posted about this problem sometime in the past here on PM? Maybe put up a link if so?

Very Interesting!!

Brent

I did but got only a couple of responses. This seems to be a very obscure problem. This is only the 4th time in about 20 years that I have seen it. Still, bad enough when it scraps parts for the the guy that it happens to. Then you never know when it rears it's ugly head again.

 

[3t3d]

This is what is happening....
The control has the current position for the beginning of the arc. i,j determine the center point of the arc.
The ending X,Y coordinates define the end of the arc.
If the end point is the same as the starting point, the control interprets this as a full circle. By definition.
If you wanted a 270 degree arc, you can see how this makes sense. If you wanted a 355 degree this makes sense.

But, if the arc is too short, under the limit of resolution for the arcs, the control does not know the difference between a TINY Short arc, or 360 degree arc.
I don't know the proper name or parameter.
Your problem is the arc segments are too tiny for the resolution of the control.
You can increase the amount of resolution for the CAM output. Output five digits instead of four.
I don't know the parameter for the control, but there is a setting for (?) arc resolution (?) Don't know the name either..

Some controls can be set to do a maximum of 180 degrees also. The CAM or POST can be set to break arcs into segments also.

Those three measures, or some of them, will solve the problem...

Don't know if any post can determine that if the length of an arc is to small to convert the G02/G03 to a G01 and ignore the I,J parameters.

 

[Evenglischatiest]

In Mastercam X8, under Settings-System Configuration-Tolerances, there's a box for minimum arc length. There's probably something similar in most programs, but I don't know where to find it. The default appears to be .0002". Anything shorter than that is supposed to become a line when you post. I can't imagine bumping that up to .0005" could make any measureable changes, on a mill. Maybe a really good lathe, but not a mill.

 

[yardbird]

Its odd to me Fanuc has no knowledge of this problem.

So this is a parameter adjustment for the minimum arc distance in the Fanuc control?

Or its a cam post adjustment? If an arc is under a minimum length to make the move a G1 instead of a G2 or G3?

Locknut: When you say completely random do you mean you cant see this on the simulation in the cad cam? So there is no telling when this will occur?

Or do you mean the offending machine only has this issue at random? Say maybe one out of five times the program is run.

Maybe the offending machine had the parameter that controls this set different then your show room machine? This is why you couldn't duplicate it with the customers program?

Brent

 

[hitandmiss]

This is what is happening....
The control has the current position for the beginning of the arc. i,j determine the center point of the arc.
The ending X,Y coordinates define the end of the arc.
If the end point is the same as the starting point, the control interprets this as a full circle. By definition.
If you wanted a 270 degree arc, you can see how this makes sense. If you wanted a 355 degree this makes sense.

But, if the arc is too short, under the limit of resolution for the arcs, the control does not know the difference between a TINY Short arc, or 360 degree arc.
I don't know the proper name or parameter.
Your problem is the arc segments are too tiny for the resolution of the control.
You can increase the amount of resolution for the CAM output. Output five digits instead of four.
I don't know the parameter for the control, but there is a setting for (?) arc resolution (?) Don't know the name either..

Some controls can be set to do a maximum of 180 degrees also. The CAM or POST can be set to break arcs into segments also.

Those three measures, or some of them, will solve the problem...

Don't know if any post can determine that if the length of an arc is to small to convert the G02/G03 to a G01 and ignore the I,J parameters.

I agree with the above as the most likely suspect(s).

Is the offending line on the control that just made the oops, exactly the same as the code on the computer that loaded the program?

There are occasions on drip feeds that will drop and/or change an occasional character. This seems to happen in places where they cause the most damage, and aren't able to be duplicated once the bad line of code is flushed to make room for more.

Bill

 

[angelw]

There are quite a few parameters that relate to the Least Programmable Increment of the control. I’m not aware of a Circular Interpolation resolution setting apart from that set by parameters for Least Programmable Increment. If the Start Radius and the End Radius of the arc being cut is outside the tolerance set in parameters, an error will normally be raise. If this parameter is set to Zero, no check is made.

If the Least Programmable Increment is Greater than actual move programmed, the control will round this to the least significant number of the Least Programmable Increment, which will be the same coordinate as the current location if the move distance is less than the Least Programmable Increment. In this case, if I, J, K Circular Interpolation Format is used, a full circle will result. If R Format is used, no move should result.

There are three Least Programmable Incremental Systems IS-A, IS-B and IS-C. The resolution of IS-A is 0.01 for metric configuration and 0.001 for Imperial. However, unless things have changed in recent times, System IS-A is not generally available. There are parameters that either multiply the Least Programmable Incremental value by 10 (1004.1) or by a value set in parameter (1820). These would be worth looking at.

As a test, I would write a simple program executing circular moves as follows:
1. All with the same Start Coordinates
2. All with the same radius from the Start Point to the Arc Centre, as described by I and J (X,Y plane).
3. All with ever increasing distances to the Arc End Point from the Arc Start Point. I would start with a Chord dimension of 0.0001 (Imperial Configuration) and increase by 0.0001.

When executing the above, if the control swings a full circle rather than a small sector, note at what magnitude of move does the control make the correct, small sector move. This may give you some clue as to what is going on.

Regards,

Bill

 

[yardbird]

Thanks Bill...

This seemed to be such an odd and peculiar issue I was wondering what your take on it would be. Thanks again.

Brent

 

[LockNut]

I agree with the above as the most likely suspect(s).

Is the offending line on the control that just made the oops, exactly the same as the code on the computer that loaded the program?

There are occasions on drip feeds that will drop and/or change an occasional character. This seems to happen in places where they cause the most damage, and aren't able to be duplicated once the bad line of code is flushed to make room for more.

Bill

First, thanks to all that commented. A lot of good ideas here. But this program is running from memory, not drip feeding. This is why arc fitting was used, to keep the program small. You wouldn't believe the resistance I get sometimes when I suggest using just lines for roughing tool paths because then the program has to be drip fed.

The fact that this program supposedly runs fine when G05.1, G05, or G08 is used leads me to believe it may be a look ahead issue on controls that weren't originally intended to handle such large amounts of code at high speed. Every single instance that I have seen this, high speed tool paths were used at 100 IPM or more.

Paul

 

[LockNut]

Its odd to me Fanuc has no knowledge of this problem.

So this is a parameter adjustment for the minimum arc distance in the Fanuc control?

Or its a cam post adjustment? If an arc is under a minimum length to make the move a G1 instead of a G2 or G3?

Locknut: When you say completely random do you mean you cant see this on the simulation in the cad cam? So there is no telling when this will occur?

Or do you mean the offending machine only has this issue at random? Say maybe one out of five times the program is run.

Maybe the offending machine had the parameter that controls this set different then your show room machine? This is why you couldn't duplicate it with the customers program?

Brent

Thanks for responding Brent. The customer is using Mastercam. He states that the operation runs fine when using verify inside MX and again runs fine when using backplot inside Cimco Edit. I have verified this inside my seat of Mastercam also. By random, I mean if the program cuts wrong on any given machine, it will always cut wrong on that machine. But you cannot foresee when it will happen. I ran this program on our showroom machine and it ran fine. Also, last year when this happened to another customer, I ran his program on our machine and it ran fine also. In addition, he sent me his MX file, I reposted the OP and sent it back. This ran fine on his machine. But I am sure I did not duplicate his arc fitting settings. I wonder if this is where the problem may lie. I still believe it is a control issue though at high feed rates. I wish I could get this program to screw up, then I could find the offending line of code and trouble shoot from there.

Paul

 

[LockNut]

Here is the offending program file if someone cares to look at it and a pic of the scrapped part.

Paul



View attachment 2D-High Speed.zip
View attachment 2D HIGHSPEED FOR DOOSAN (2).zip