Accuracy of IJK vs. R for arcs

I ran into a problem last week with HSMWorks on a HAAS VF3 Mill. I was milling a circle that was 8.17" in diameter with a bore of about 3".

The OD was cut in a football shape with the x axis dimension being 8.17 and the y axis dimension being 8.135". So there is about .035" difference in the 2 directions.
I determined in the cimco back plot window that the arc center was being calculated off center by.0173" and .0007 the axis. The tool path was split into 2 arcs on being .0173 above center and one being .0173" below center.

This is the second time I have had HSMWorks code scrap parts for what should have been a simple circle. I thought it was fixed after the first time and to be fair this is a different error I guess, but still revolves around the same kind of issue.

I used the "R" word for the arcs, HSMWorks IMO is passing a wrong start point to the arc and when the arc center is calculated it is off by a magnified amount. I am being told it is a control issue since the CNC control can't compensate for the bad start point. Sounds like bull to me. How could a control compensate for a bad start point from the software.

I have never had any issues with using the R word in other software. I also realize thru this that any error in start position could be easily magnified in the error the arc center is off. I will be using IJK from now on as the problem does not seem to occur with that code since the center is explicitly defined and can handle a little bit of start point error.

Here is a link to the discussion.
Solved: Re: Arc center is not correct - Page 3 - Autodesk Community

Has anyone seen these kind of errors in generated code before using R word for arcs? I mean this was a real eye opener for me that a start point being off .001" could throw the center off .0173?

Here is an example of some of the code I am getting. This error is only about .014 vs the .017 but still pretty bad. Arc center should be 0,0 for the G2 arcs and a 8.17" diameter with a .5" endmill

Actually, I have seen just this.

After plugging your coordinates into Autocad, they are accurate to less than .00003
My case was also very similar, and also with large(r) arcs.
180 deg arc, accurate start/end/radius and it also became a football looking thing.

Without doing anything else, changed the R to I and J and the path was perfect.

I think Haas has an issue with exact 180deg arcs on larger radiuses.

After that I've modified my post to always output I and J, no problem ever since.

P.S.
I've just read a bit into the end of your HSM works thread, and I tend to agree with the support guy suggesting I and J.
Let's assume your exact example having a programmed X value of 4.3313.
As far as the control is concerned, that can be 4.33125 and 4.33135.
If you plug those values into Autocad, then the corresponding Y values are .17785 and .18027.
Haas allows errors up-to .001 in the input coords, so X4.3313 Y.1785 R4.335 is perfectly within it's allowance.
In fact, you would end up with an accepted code in both of these cases:
X4.3313 Y.1778 R4.335
or
X4.3313 Y.1803 R4.335

I am not saying one way or another, if it is an HSM issue or Haas, but I and J SHOULD be more accurate and repeatable.

Believe me I am IJk man from here on out! I understand what you and Rene are saying, but what I am not grasping is how it is really a control error. I can pick up the error in Cimco edit? It may be a R issue for sure but not a control issue IMO. I would be curious how a fanuc would cut with that code.

I agree that it's not a control error; AFAIK, it's a fundamental error that exists in every control that allows the use of arcs defined by an R command. The arc isn't fully defined, and as such the possibility for an incorrectly calculated center point exists.

To be more specific, fanuc programming manuals contain language that points to the existence of this problem, and effectively warn to use IJK to avoid it.

csharp said:

I would be curious how a fanuc would cut with that code.

Click to expand...

Me too.
Don't have one to test on, but curious as to how it does the math and to what is "boss" in the position calculation.

I know ACAD ( or any other decent CAD pgm ) can resolve it to the 15th decimal and would not consider the intersection point otherwise, but the CNC control doesn't really care
to that degree and may not compute the trajectory to that degree.