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.

[terry54]

I was instructed by an AE for a large OEM to never use r, always use IJK delta start to center. This is for all cam programs. I was told the arc tolerance would be off, and he worked for a high end machine mfg.

[Lonnie.Cady]

Thanks the racetrack analogy makes sense.

I know the rough and finish are not connected directly.  But the end of the final linking move for roughing changes with the change in rough smoothing deviation.  So the bigger the smoothing deviation the "wider" the race track.   The final linking point for roughing is the start point for finishing.  So when you have a wider race track it appears to me as the final linking point can be farther out of position and that in turn is the start point for the arc.

I appreciate your time and don't expect you to keep explaining.  I don't really know how to communicate what I am thinking at this point.  It might not even be correct thinking.

Thanks again.

[Steinwerks]

@fonsecr

What control could ever calculate a correct arc using R with an incorrect start point? There simply isn't enough data to correct for the error in the code. The control just uses the numbers it's given.

This is a prime example why I was warned in school to be wary of using radius for arcs, and so I simply never have.

[fonsecr]

---

@Lonnie.Cady wrote:

So the bigger the smoothing deviation the "wider" the race track.

---

Yes, exactly. But still making sure maximum stepover is not violated.

[fonsecr]

---

@Steinwerks wrote:

@fonsecr

What control could ever calculate a correct arc using R with an incorrect start point? There simply isn't enough data to correct for the error in the code. The control just uses the numbers it's given.

This is a prime example why I was warned in school to be wary of using radius for arcs, and so I simply never have.

---

The answer is no CNC control. But that is the case of any G-code in general 🙂 The general question would be if the CNC does the motion within the desired tolerance for given G-code. And it just seems that R-word makes this significantly less likely. Where IJK is working just fine for general use.

[MattWallaceVRTX]

This is a fascinating discussion.  Like others, I had heard and read that IJK was preferred over R, but never understood why it would make a difference, chalking it up to CNC programmer folklore (I use IJK anyway, on the off chance there was something to the tales).  After this, I made a couple of sketches to test this out.  A .001mm change in radius on an 100mm radius arc will cause the midpoint of the arc to be out of place by .44mm, .017in.  The Haas that constitutes my entire practical CNC experience has .001mm resolution encoders.  If running in inch mode with .0001 resolution, there is a lot of room for rounding/truncating to intruduce a .001mm error.  Running in mm mode will reduce, but not eliminate, this source.

When running IJK, the arc center is explicit and the control internally calculates the radius, rather than the other way around as it does running R.  Given this, I would only run R if I had no choice.

IJK also has the theoretical advantage of erroring out if the end point is not on an arc with the given center.

[fonsecr]

Hi @MattWallaceVRTX,

FYI Post team has updated all posts in the post library https://cam.autodesk.com/posts accordingly also. So we use IJK whenever possible by default.

[Lonnie.Cady]

still having issues,  can some on back plot this using the haas turning template and see if they see the same thing.

G0 Z0.085
X0.3698
G1 X0.4405 Z0.0496
Z0.0046
G2 X0.435 Z0.0031 I0.0027 K-0.0086
G1 X0.3643 Z0.0385
G0 Z0.085
X0.3753
G1 X0.446 Z0.0496
Z0.005
X0.4441
X0.4423 Z0.0048
X0.4405 Z0.0046
X0.3698 Z0.0399
G0 Z0.0403
X0.3753
G1 X0.446 Z0.005
Z0.
G2 X0.4382 Z-0.003 I0. K-0.004
G1 X0.3932 Z-0.091
X0.3931 Z-0.0915
X0.393 Z-0.092
Z-0.327
X0.3223 Z-0.2916

[bob.schultz]

Hello Lonnie,

This seems to another problem with the Backplot function.  Here is the screen shot when using the Haas Turning setup.

Notice that the center and radius of the circle are incorrect.  It is quite easy to determine the correct circle center and radius when I=0 and J=-.004.  The radius is obviously .004 and the center should be .4460,-.004.  Here is a picture of the backplot when using the ISO Turning post.

Here you see that the plot is correct and the center point (IJ) and radius (R) are calculated correctly.

[Lonnie.Cady]

@bob.schultz yep, I don't necessarily disagree and had tried the iso template.

However a couple of more points/questions

1. I guess it is safe to assume that the templates for the backplotter never get fixed?  we just get what we get?  There are other issues with using the haas template.

2. I use the backplot editor with my other lathe cam software and have never once had this issue.  I mean literally never have it.

3. I can show you in the exact same file that the od tool paths were doing the exact same thing and adjusting the smoothing setting in the cam software made them go away.  So while I again don't disagree with you, the code being sent to the backplot is having an effect on the backplot display.  

So if the problem is the backplotter yet changing the smoothing setting also affects it how it one to really know without some investigation every time. I guess it just does not feel like a very robust solution at this point.  I guess ultimately there  is not really any point in it since the backplotter is going away.  Which on it own is sad because it has helped users track and report bugs back to ADSK.

[Lonnie.Cady]

@bob.schultz actually from what I can tell the iso template is the ONLY one it displays correctly in.  I have even tried it in a completely different editor and results still failed.

[bob.schultz]

Hello Lonnie,

The example in this discussion is just too obvious a solution, so I cannot fathom how the Backplot routine does not calculate the correct center and radius for the circular interpolation move.  The Backplot routine does have options for circular interpolation records and the Haas settings match the ISO settings, so what it is thinking internally one can only guess.

A colleague here ran the same NC code against NC Corrector and NC Viewer and NC Corrector plotted it wrong while NC Viewer plotted it correctly(???).

The only advice that I can give is to increase the minimum radius and chordal length for circular interpolation records in the post.  It may have something to do with the small numbers, but as I already mentioned the solution here is too obvious for a failure as you are seeing.

 minimumChordLength = spatial(0.25, MM);
 minimumCircularRadius = spatial(0.25, MM);

Give these numbers a try and see if you get any more errors during plotting.

[Lonnie.Cady]

Thank you @bob.schultz and @xander.luciano for discussing this issue.  I will just drop it.  I do understand what you are saying. I have plotted g code with this editor for 5 years and never an into this.  Who knows!!

[Lonnie.Cady]

@bob.schultz

actually I have just one more question, What would you recommend as a solution that is robust enough to tell where errors are occurring?  That is a serious question.

Fisrst time I had an issue with arcs I scrapped an order of parts and it was actually an HSMWorks error and was fixed.  The back plotter actually helped me track down the problem.  Second time I scrapped parts I was told that it only occurs when using R for arcs and arcs that approach 180 deg.  Was told to never use R since the smallest error can magnified.  ADSK changed post to default IJK and I changed all my post to use IJK.  Now I can't properly back plot arcs other than the ISO template when using IJK.

In the above example we were discussing using R.004 back plots correctly.

So again what is a robust dependable solution?  

At this point I can't trust HSMworks, can't trust back plot and can't trust R for arcs.

[bob.schultz]

Hello Lonnie,

I can see where you have misgivings about trusting circular interpolation, especially in light of the actual HSM problem.  It is kind of funny, as I have been in this business for a lot of years and there are still circular interpolation problems.  One would think that these would have been resolved many years ago.

First, as far as using Radius programming goes, there will always be a problem because numbers output to the control are truncated to 3 or 4 digits.  The controls and Backplot routines have to use these truncated numbers to calculate the center of the circle and in a perfect world the center can be a couple of thou off when using truncated numbers.  One of the test cases I evaluated was documented to be .017 off, but not due not to the output, which was valid, but to the calculation used in the Backplot routine.  Unfortunately, this calculation could be off in machine controls also, which is one of the main reasons we recommend not to use Radius programming.

Radius programming was added to controls to facilitate hand programming and is really only accurate with moves that start and end on quadrant boundaries.  Using IJK defines the exact location of the circle center, so eliminates this problem,  EXCEPT it seems in the case that you supplied.  The solution in this case is so straight forward though, that I cannot even guess as to what the Backplot routine is doing internally to calculate such an errant solution.  I will bring up this problem to my colleagues and see if there is a solution or at least a way to send it to the developers so that they can take a look at it.  The problem being is that if it fails on 2 of 3 Backplot programs, are there controls that it will also fail on?

The calculation problems of machine controls is out of our hands and all we can do is try to work around them.

As an answer to your question, you should change the minimum values as I explained in my previous post and see if you start getting good results in Backplot.  It is quite possible that the problem only appears on very small circles, which is something that I have run into many times with different controls over the years and why we have these values in the post.  If the control does not process small circles correctly, then the only thing that we can do is output these as linear moves.

[Lonnie.Cady]

@bob.schultz my exact feelings, you would think most of this would have been resolved by now.

Yes the example is rather obvious but there are many times going from an angle to angle it is not so quick to figure. I downloaded Cimco edit 8 and it appears to display correctly.

Thank you again.

[Greg_Haisley]

The STL model in the background that HSMWorks slices for toolpath generation is the root cause of this problem. You can not get correct geometry from a sliced STL model. You will get different length segments depending on the quality of the STL model. Regardless of the quality of the model, you will still get segmented lines even on a perfect flat face.

The older CAM systems used 2D sketches or 2D dxf files to develope the toolpath for a lathe. They would just create an offset of the drawing geometry. This offset would be the theoretical toolpath for the center of the nose radius of the tool.

With HSMWorks there is no best fitting of entities generated from the STL slice. What I mean here is there is not an algorithm that anaylises the 3D model slice and best fits lines were lines should be and arcs that are tangent to the best fit lines. This is why the lathe toolpath has so many segments from even the simplest of geometry. If you have a sketch to drive the toolpath, you should get a correct toolpath like the mill side does.

This is my opinion. If you don't agree, then by all means post what you think is the problem.

All I know is, there are a lot of 2D lathe turning packages out there that do not experience this same problem.

The ends my Tuesday rant.

Have a great day.