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.

[Laurens-3DTechDraw]

Thanks René!

[popaa · Accepted solution]

Hi Lonnie,

I have fixed the issue. It will come out in a future release.

Aurelia

[fonsecr]

Fixed in latest HSMWorks development release. 

HSMWorks2016-R3.40936 / June 6, 2016

René

[parobillard]

Hi everyone!

I've posted a similar problem in support forum. In my case the toolpath was off by 0.031" (0.78mm) thats ALOT!

I guess it's the same fix!

thank you 

PA

[Laurens-3DTechDraw]

---

@parobillard wrote:

Hi everyone!

I've posted a similar problem in support forum. In my case the toolpath was off by 0.031" (0.78mm) thats ALOT!

I guess it's the same fix!

thank you 

PA

---

Could be.  Since you are on Inventor HSM you might not have recieved the fix just yet. Or this problem might not have been in there.

[al.whatmough]

This was resolved in the June 28th Release of Inventor HSM

http://cam.autodesk.com/inventor-hsm-experimental/

[Lonnie.Cady]

2 more scrap parts!!!!!!!!!!!!!!!

This time in fusion, it was a complete circle and the parts are .035" out of round.    Arc centers are .0173 off center for each half.  When it does the upper half it is .017 below center and then when it does the lower it is .017 above center.

You can visibly see it in the chamfers as it generated fine.  Nice chamfer in x axis and none in the y axis.

How the hell are we supposed to have any confidence in the arcs being generated.  I can't go thru and mathematically check every arc.  I mean I had a +/-.010" and could not even trust the software to hit it.  This is beyond acceptable.

@al.whatmough

@fonsecr

@popaa

[Greg_Haisley]

When a CAM company can't process 2D geometry correctly they have a huge problem on their hands. The fact that this got released without valid testing is even more disturbing. Wow.

[Lonnie.Cady]

@Greg_Haisley, I was pretty upset about it, but what is troubling the lack of response from anyone on it.  I assume it affects all 3 products.  

Makes me wonder how many of the arcs I have machined on none critical features were really out of position.

If you use IJK in the post processor vs "R" it works fine. The arc center point using IJK is explicitly define by coordinates.   When using "R" the center point must be calculated from the start point and the "R" and the sign of the "R".    As I believe they are seeing a small error on start position can really throw the arc center off.  In this instance the start point was off by .001" but the arc center was off .017"

The bigger arc the larger the magnification.  This arc was at a diameter of 8.17"

On the first part I scrapped when I started this thread the diameter was some where around 4" and the error was about .005" on arc center.  IIRC

[cj.abraham]

As Lonnie said, this issue is unique to using R output for arcs. The reason for the error is that two "rights" made a wrong.

The start and end points of the arc are well within tolerance (keyword "within"), and the R value is the exact radius of the selected geometry (keyword "exact"). The problem is that as the start and end points move within the tolerance, the radius of the arc must also change to fit within what would be the profile tolerance (think GD&T). The radius of the arc was not changing because the exact value was being used. The result is the problem described in this thread.

The current recommendation is to use IJK for arcs, but there is an open ticket to fix this problem for posting using arc radius. CAM-4191

[Laurens-3DTechDraw]

@cj.abraham

Just made a little sketch. And indeed if the start and end point are off by 0.01(the default tolerance). The midpoint is off by 1mm. Which is insane compared to the tolerance indeed. This also means of course that the move would no longer be tangent to the previous straight line.

[Lonnie.Cady]

@Laurens-3DTechDraw yes that is exactly how I determined the error was the start/end point.  I plotted the points from the gcode in SolidWorks.

One of the troubling issues also is we were told that cam ticket was fixed now we are being told it is still open.  So maybe it was never completely fixed the first time.  Would have been good to know that it was not really "completely" fixed.  I guess I am just fortunate it only cost me time, material and wages.

[Steinwerks]

---

@Anonymous.abraham wrote:

As Lonnie said, this issue is unique to using R output for arcs. The reason for the error is that two "rights" made a wrong.

The start and end points of the arc are well within tolerance (keyword "within"), and the R value is the exact radius of the selected geometry (keyword "exact"). The problem is that as the start and end points move within the tolerance, the radius of the arc must also change to fit within what would be the profile tolerance (think GD&T). The radius of the arc was not changing because the exact value was being used. The result is the problem described in this thread.

The current recommendation is to use IJK for arcs, but there is an open ticket to fix this problem for posting using arc radius. CAM-4191

---

I got the same issue when I set tolerance to .00001" in Lonnie's file. No difference in toolpath whatsoever. I even went so far as to set every tolerance via the Compare and Edit dialogue to .00001" or smaller. Still no change in toolpath, and they post the exact same code. It's a bug that has nothing to do with tolerance settings as far as I can test it.

[Laurens-3DTechDraw]

@Steinwerks

In the original file Lonnie send me when this issue occurred first it seems fixed.(Was in HSMWorks)

I just copied the wrong operation. Re-generated it and it was correct. But there the issue also showed in the CAM side.

And I believe now you cannot see the issue in the CAM side but only after posting in Fusion360?

[Lonnie.Cady]

The gcode error is exactly the same when posted from HSMWorks as well as fusion.  This is probably expected since they share the same kernel.

I would disagree that the fix is to adjust the "R" radius.  The issue is not the R value but the start/end points.  Changing the R seems more like a hack.  The software has already determined the radius and the center of the arc.  Problem is the start point is not on that radius.   

This is the problem with HSMWorks and their support, THERE IS NONE!

I reported the original problem 5/2 not one response from support/developers.   @Laurens-3DTechDraw was kind enough to look into it and verify it was a an error.  Still no response.  Final Laurens pings the developers to finally get some help.

[Laurens-3DTechDraw]

---

@Lonnie.Cady wrote:

The gcode error is exactly the same when posted from HSMWorks as well as fusion.  This is probably expected since they share the same kernel.

I would disagree that the fix is to adjust the "R" radius.  The issue is not the R value but the start/end points.  Changing the R seems more like a hack.  The software has already determined the radius and the center of the arc.  Problem is the start point is not on that radius.   

This is the problem with HSMWorks and their support, THERE IS NONE!

I reported the original problem 5/2 not one response from support/developers.   @Laurens-3DTechDraw was kind enough to look into it and verify it was a an error.  Still no response.  Final Laurens pings the developers to finally get some help.

---

@Lonnie.Cady my point is that your original file is fixed with the current HSMWorks version.

So I'm not sure if it was never fixed in Fusion or that we have a similar or different issue now.

Because your original part also showed the problem in the simulation where the new one in Fusion doesn't show the problem in the simulation right?

Because if it would show in the simulation you would also have an issue with IJK output.

I would expect the new problem to have arisen when they fixed your old problem.

[Steinwerks]

---

@Laurens-3DTechDraw wrote:

Because your original part also showed the problem in the simulation where the new one in Fusion doesn't show the problem in the simulation right?

Because if it would show in the simulation you would also have an issue with IJK output.

I would expect the new problem to have arisen when they fixed your old problem.

---

Here it is in Fusion (sketched point added by me, derived from start point using generic Haas post and useRadius):

[Laurens-3DTechDraw]

Transition moves should be non-cutting. It's the cutting passes that matter.

But besides that I'm not sure what I should see in that screenshot.

[Steinwerks]

That's the start point of the finish pass arc. The next one arcs around half of the part creating the error that shows up while useRadius is used in the post. As can be seen in the screenshot, the tool isn't touching the part at all and it should be tangent. It's difficult for me to get a good screenshot of this. It also ONLY shows up with roughing passes on, which means I suspect it's a linking issue.

I made a template of Lonnie's toolpath (nothing weird in it, just wanted to make sure it was the same) and brought it into HSMWorks. Of course without forcing an entry location I can't get the two CAM systems to agree on a quadrant entry, so that makes comparison difficult, but in the code posted by HSMWorks (same part geometry) I get a proper toolpath with no error.

Wherever the error is, it's in Fusion specifically and not HSMWorks/SolidWorks.

@Lonnie.Cady can I add the .F3D file I sent you to this thread?

[Lonnie.Cady]

@Steinwerks that is my feeling also, endpoint of transition is the start point of the arc.  If you change all the .1733" to .1742" in the backplot you will see that the arc center moves back to (x0,y0).  The other way is what @cj.abraham suggest and change the r from 4.335 to 4.3349.

As for HSMWorks I get the exact same code, as in incorrect arc center as I do in Fusion. 

Both plot the arc center at .0173" and .0007" for x and y.    Make the changes above and they become 0,0.

The the other work around for the first bug of setting min cutting radius to zero does not appear to work either.

I found another solution that I used.