arc generation "errors"

[camguy]

nc programs commonly are generated to 4 decimal places (inch), nci files are created to 6 decimal places. some rounding off is happening in this case. if the contoller on the machine uses a trig function check, this could cause errors on the machine as the end points of the arc are not relative to the I and J co-ordinates. in this situation an arc is not always an arc as defined by it's end points/center point.

I generated this program and compared the nci to the nc code

NCI .611855 -0.988596 -0.1375

NC X.6119

NCI .174403 -0.664322 0.611911 0.126886

NC G2X-.1744 Y-.6643 I.6119 J.1269

NCI -1.230973 -0.687685 -0.691446 -1.184388

NC G3X-1.231 Y-.6877 I-.6914 J-1.1844

NCI -2.323136 -1.166711 -2.323136 0.317849

NC G2X-2.3231 Y-1.1667 I-2.3231 J.3178

NCI -2.93499

NC G1X-2.935

on most machines this would not be a problem

just my 2 cents on the subject

camguy

[Guest]

I can see how that could cause the physical arc to be different than the electronic one, but I would think that the start and end points of the arc would be matched with the previous and following blocks. So while the arc is not identical to the cam file, it should come out of the cam file as a match for the 2 blocks on either side of the arc.

Perhaps the software engineers at MC will enlighten us as to whether or not the arcs are matched with the surrounding block's start/end points. Rekd

[This message has been edited by FukNRekd (edited 02-08-2001).]

[Mark H]

Camguy, this is what I think is happening in my Mazak (Mazatrol M plus controller). As I stated before, the arcs work 99.9% of the time. Verify shows that program is okay, but the scrapped part tells me otherwise. No, I dont always do dry run, especially on the long run programs I use for mold work. Thanks for your 2 cents. I wonder if there is a setting in my controller that I could adjust? Anyone familiar with Mazak controllers?

[This message has been edited by Mark H (edited 02-08-2001).]

[Charles Davis]

I have a thought on this.

I kindof doubt this is a round off problem, since Mastercam always (in my experience) rounds properly.

Whenever I've encountered this problem in the past, I go into the post and set breakarcs=yes. That breaks the arcs at the quadrant points.

What may be happening is (from the controls point of view) there are two solutions to the arc; given the code.

That would explain why the on-control program is working, and the g-code from Mastercam (which is good code) is failing.

This produces more code (4 blocks for a 360 degree arc rather than 1-2), but the reliability is worth it.

For the same reasons of reliability, I generally use i's and j's instead or r's. [Though I've never had a problem with r's on the Haas control, I have on others].

Just something you may want to try. It's always worked for me.

Charles Davis

Davis Technologies

Poway, CA

[Mark H]

Charles Davis,

I'll give the "breakarcs=yes" a try, currently I have it set to no. I also use I, J and K. I think I saved that problematic arc nci file somewhere on this 10 gig hard drive... If I find it I'll post the results here.

As for the rounding thing, I also think Mastercam is fine, but going from one system to another could be a problem.

[tgaul]

Charles you are correct.

If two arcs or a line and an arc intersect there will be two possible intersection points. The trig help function is just an aid in finding that point when it is not known.

When running programs from a CAM system the trig help may calculate the incorrect intersection point.

Milltronics recommends turning this function off with any file generated from a CAM system.