Arc center is not correct

[Lonnie.Cady]

Has anyone experienced any issues with the arc center not being correct in milling?

I have a 180 deg semi circle and its center is located at x0 y0 but the the tool paths in SW is off and the posted code show the y center being off .0043"

I drive the tool path off the edge of the model and it is off.  I created a sketch circle that is concentric to the model and if I cut a full cirlce the toolpath and code are correct?

In the below I have duplicated the operation and selected both so both toolpaths are displayed. One is drive off model edge and the other off sketch. You can see in the first image they overlap.  As you approach the top they no longer line up.  I can't share the file publicy.  I shared it with @jeff.walters.

Was more curious if anyone else was seeing this.  I found it by cutting 2 parts and putting them together and they were correct across the split but off .009" the other direction and scrapped the first sets.

[Lonnie.Cady]

@Laurens-3DTechDraw,

The same problem exist in IJK.  That is the start point is technically still out of location.  However the center of the arc is explicitly defined by IJK.  when using R the center is calculated which is floating in relation to start points.

[Laurens-3DTechDraw]

@Lonnie.Cady @Steinwerks So the path looks correct in Fusion360? That is the main question I want to get answered.

@Lonnie.Cady 's original problem in HSMWorks(That started this thread) showed a wrong path in the CAM environment. Where now if I understand you two correctly it's mainly a CAM->POST->Machine conversion problem.

So I think we can conclude you get the same scrapped parts but it's a different issue that causes it.

---

@Lonnie.Cady wrote:

@Laurens-3DTechDraw,

The same problem exist in IJK.  That is the start point is technically still out of location.  However the center of the arc is explicitly defined by IJK.  when using R the center is calculated which is floating in relation to start points.

---

 If that is the case changing the radius that is given to the post would result in the same path as using IJK right? Because when using IJK the machine would just change the radius to fit the start,end and center points.

[Lonnie.Cady]

@Laurens-3DTechDraw

I give up, I have no other information that I could offer at this point. 

I have never seen such an issue in 2d arcs in 25 years of machining period.  I don't have the time/knowledge/resources to try to debug or figure out the problem I assume that is what developers are for.   I have wasted enough time and material debugging it. 

I appreciate your insight on this.  Sounds like I have 2 solutions available to me use IJK or SmartCAM.

[Anonymous]

here's a 10" x 20" oval prog, same part. Inv HSM and geopath. the HSM leaves a mark. no sense why it programs like this.

HSM

G0 X0. Y5.25
G1X10.F55.
G2 X15.25 Y0. I0. J-5.25
X14.499 Y-2.7058 I-5.25 J0.
X10. Y-5.25 I-4.499 J2.7058
G1 X0.
G2 Y5.25 I0. J5.25
G0 Z0.1

GEOPATH

G0 X0. Y5.25
G1X10.F55.
G2X10.Y-5.25J-5.25
G1X0
G2X0Y5.25J5.25
G0Z-.1

[Laurens-3DTechDraw]

@Anonymous that's another thing. There Inventor HSM didn't calculate it in one arc but in three. While it probably shouldn't do that is a different issue. Usually fixed by changing the tolerance and turning smoothing on.

[Vohnsen]

I have never seen this problem.. is is everytime you do circles? 

This is a serious problem

[Laurens-3DTechDraw]

---

@Vohnsen wrote:

I have never seen this problem.. is is everytime you do circles? 

This is a serious problem

---

@Vohnsen

It seems to pop-up mostly for half circles I believe. But could technically happen on any radius I think.

Do you run the machines with IJK or R in G2/G3?

You would only see this in R not in IJK.

[Vohnsen]

Ok that might be why... I've never been a fan of using R when milling.. even when im manual making a program i always use IJK..

[Steinwerks]

As far as I can tell this error only shows up with roughing passes on.

[fonsecr]

I got the example to look at and the generated toolpath is correct. The R-word issue is unrelated to CAM-4191.

The problem happens because the coordinates are rounded to the requested number of decimals in the post. Commonly 4 for inch mode. And on top of that when using R-word for G2/G3 this will be very sensitive to the rounding. Using IJK is much less sensitive to rounding noise. Based on this IJK is recommended over R. For say 180deg arcs that can give a big deviation at the mid point.

The post engine is only formatting the toolpath to the desired output. It will not try to fit new motion to handle compensation for rounding since it doesn't cannot know the intent of the specific coordinates in the NC program. It would be possible to add code in the individual posts to do various alternatives for G2/G3. Will think about that. I opened CAM-6211 for that.

[Lonnie.Cady]

Maybe you want to consider putting out a bigger warning than something buried in a thread.

People may want to know that their parts could be off like mine up to .035" by using "R" with all tolerance/smoothing deviation set to .0004"

The problem only occurs when roughing passes is on as far as I can tell.  The problem appears to be that the end of the linking move from the final roughing pass, while in tolerance is not actually coincident to the arc being cut. 

If I set the roughing pass smoothing deviation to "0" I appear to get the proper arc and arc center.  I can only assume since there is no smoothing that the end of the roughing linking move falls coincident to the arc being cut.

I am not sure it is possible but why not consider applying the smoothing deviation to the roughing as normally but internally set the deviation of the final linking pass between rough and finish to "0".  This would force the final linking move to be coincident to the arc.

Or since the final linking move of the rough pass needs to end in the tolerance of the finish pass since the end point of the rough linking becomes the beginning of the finish.  Maybe you should apply the finish smoothing deviation to the final rough linking pass.

Even a smoothing deviation of .00005" shifts the arc center off .005".

[fonsecr]

The R-word issue is not related to the toolpath in Fusion. I can see to R-issue just in an edited NC program.

I have now done the error calculation on the radius due to rounding of XYZs and the error is not significant in itself so it is a combined effect. You can limit the arcs in your post to 90deg when using R-word which seems to avoid the issue.

I'll keep looking at this.

[Lonnie.Cady]

I understand the error is not significant I also understand that while the toolpath from Fusion is with in tolerance that the result is not good.

I was just offering up that the roughing smoothing deviation being set to "0" resolves the amount of error being sent to the post.

So setting the smoothing deviation to zero for the final linking may eliminate the amount of positional error being passed to the post, which results in a magnified arc center issue.

If you look below you will see .0008"difference in the y start point.  Yet a .0142" error in arc center.

roughing smoothing deviation =0
this one has correct arc center at 0,0

G3 X4.3313 Y-0.1793 R0.0164
G2 X-4.3313 Y0.1793 R4.335 F60.
X4.3313 Y-0.1793 R4.335
G3 X4.3792 Y-0.2313 R0.05 F30.




roughing smoothing deviation =.0005"
this on arc center is off .0142", .0006"

G3 X4.3313 Y-0.1785 R0.0164
G2 X-4.3313 Y0.1785 R4.335 F60.
X4.3313 Y-0.1785 R4.335
G3 X4.3792 Y-0.2305 R0.05 F30.

I will not be using R anymore period.  But this does not instill an confidence that there are not other issues that have just been discovered yet.  I also don't understand the reluctance to issue a stick post warning explaining it to others.  Or at least something to warn them.  Maybe a quick video why not to use R for arcs.

[fonsecr]

@bob.schultz helped check this also. And we see where the problem comes from now.

Basically some CNC controls will not calculate the correct center when using the R-word. Using IJK-words will have the center specified directly so that wont expose the bug in the CNCs. Which is why we haven't seen that problem before - as IJK is the default for most posts.

The bad center problem can happen for arcs close to 180deg when the CNC doesnt compensate internally for the rounding to the given decimals in the NC program. And as you have seen that can be a huge error.

So what we are going to do is to update all posts to only allow up to 90deg arcs when using R-word. IJK wont be limited and IJK is still recommended. The G-code output is correct as it is for R-word - so if you really wanted to have 180deg G2/G3 support then that could be allowed but it would be up to you to make sure your CNC actually works which will be tricky to test in general. It will be hard to find out what the CNC does in all the possible cases.

There is no away we can know which CNCs will have this R-word problem so that is why we are choosing the safe approach here and setting the 90deg limit for all ISO posts when using R-word.

[Lonnie.Cady]

How can it be a CNC control error when it occurs in the posted code before it even gets to the CNC?

It occurs with the fanuc post also. The backplotter also shows the error BEFORE it gets to the control.  How would the CNC compensate internally for being given a bad start point? The CNC is dumb and just executes the code given.  What if I wanted to cut it like a football and the control keeps assuming that it is a bad start point.  The start point is NOT tangent to the arc being cut when rough cuts are done.  It may be close but it is not tangent and there for moves the arc center.  You can't blame the control for doing what it was told.

I guess we will just have to disagree on this issue.   

[Laurens-3DTechDraw]

---

@Lonnie.Cady wrote:

roughing smoothing deviation =0
this one has correct arc center at 0,0

G3 X4.3313 Y-0.1793 R0.0164
G2 X-4.3313 Y0.1793 R4.335 F60.
X4.3313 Y-0.1793 R4.335
G3 X4.3792 Y-0.2313 R0.05 F30.




roughing smoothing deviation =.0005"
this on arc center is off .0142", .0006"

G3 X4.3313 Y-0.1785 R0.0164
G2 X-4.3313 Y0.1785 R4.335 F60.
X4.3313 Y-0.1785 R4.335
G3 X4.3792 Y-0.2305 R0.05 F30.

---

So alright the arc center problem is exaggerated by using R in the code.

But if I look at that code I see the Y is different by 0.0008. That's double the default tolerance.

So or Lonnie set a big tolerance or I would say the path in general is off by more than the tolerance.

But this depens on the line before the first G3.

[Lonnie.Cady]

@Laurens-3DTechDraw it appears this can be a problem on all machines when using the R word for arcs.

I have found very little info on it, but have drawn/plotted the points in SW and you can easily see what is going on.  It is actually difficult to plot the exact points since SW checks out the accuracy much farther than 4 decimal places. I would keep ending up with over constrained or unsolvable situations since the arc in the code at 4 decimal places is technically impossible to create in SW.  At least for me.

Rob mentioned on another forum that there is some of this mentioned in a Fanuc manual.  I don't have any  Fanuc manuals so I can't tell you what it actually says.

[fonsecr]

1. The 90deg sweep change in the posts addresses the issue where the CNC would potentially do something different than desired in the NC program.

2. When you use the smoothing deviation feature it will fit in new arcs within the given allowance so in that case you would get different arcs than in the selected geometry. But as long as the visualized toolpath matches the NC program then that is as expected. This is normally used for roughing/semi-roughing where you dont care about the actual passes.

3. So only problem would be if you get toolpath than is wrong for the given settings. If you see this then please submit such examples to support.

[Lonnie.Cady]

@fonsecr thanks for looking into this.

I am not trying to argue with you on this, I just don't think I fully understand one issue.  You are correct in that smoothing deviation is normally used for roughing and semi finishing.  However the end point of the roughing is allowed to deviate with in the tolerance.  The end point of the roughing is the start point of the finish which may have a different smoothing deviation.  So why would the start point of the finish be held to the smoothing deviation of the rough pass?

This can be seen by setting the smoothing deviation of the rough pass to zero.  

Forget about the arc center issue for just a moment, as this question is more of "is the START point for finish passes" being held to the tolerance/deviation of the roughing pass?  If so should it?  Obviously the endpoint of each move is the start point for the next.

The below test leads me to believe it is.

Rough Smoothing in deviation set to default .004"
arc center is incorrect
X4.3421 Y-0.1586 R0.0162
G3 X4.3315 Y-0.1733 R0.0164 <------is this the end of rough or start of finish? what tolerance is this held to?
G2 X-4.3315 Y0.1733 R4.335 F60.
X4.3315 Y-0.1733 R4.335

Rough Smoothing in deviation set to .0000"
arc center is correct
X4.3419 Y-0.1646 R0.0162
G3 X4.3313 Y-0.1793 R0.0164  <------is this the end of rough or start of finish? what tolerance is this held to?
G2 X-4.3313 Y0.1793 R4.335 F60.
X4.3313 Y-0.1793 R4.335

In the attached is a file with 2 operations for anyone that may want to see what can happen, edit and compare will show the only difference is the rough smoothing deviation.  When you post both ops and open in a back plotter you can see they are not over top of each other.  The rough or finish passes and the arc centers vary buy .017"

This has been a huge eye opener for me. Not sure if it was for anyone else.  I will likely never use "R" again.

[fonsecr]

Thanks for the example. Makes it a lot easier to review.

The smoothing deviation is not a tolerance. When an operation clears an area it doesn't matter where the toolpath is as long as the area is machined within the given requirements (settings like stepover).

When smoothing deviation is used the strategy will adjust the cutting passes to reduce sharp directional changes within the toolpath. The smaller the smoothing deviation is set to the smaller the less flexibility the strategy will have to fit in a smoother cut. It is kind of like following a race track around and cutting all sharp corners off and the tool can be anywhere on the track. So it is by design that you get different toolpath when adjusting the smoothing deviation.

Not sure what you mean by start and end points not matching since the passes are not connected when generated. Rather the transition linking moves between the passes will be what connects the cutting passes. And the transitions will just move smoothly from one cut to the other. But since the roughing passes are different then the transitions will also be slightly different.

I guess that you could get marks on the parts for at the transitions end point and start of finishing cut when the center can move when using R-word. It would depend on how the CNC interpolates the G2/G3 - if it could overshoot the end point that would be bad. Using IJK would be better since CNCs generally interpolate smootly from start of end of the G2/G3 allowing for a little spiral at the same time. This keeps the motion smooth and avoid overshooting of the start/end points. I guess there is more room for undesired motion when using R-word on some CNCs. I would have expected the CNCs to be smarter and in general do something similar to IJK mode but still with some chance of undesired motion.

I would recommend IJK over R when available. At least we haven't hard about this before and IJK has been the default for most of our ISO posts.

PS. If there where special cases you wanted to test the easiest would probably be to force retracts and use an entry position to force the leads as a particular point along the finishing cut.