I'm writing GCode to cut a polygon with several arcs in it.  In one place,  three arcs follow one after the other and Mach shows an error reading the block for the third arc with the  "Radius to end of arc differs from radius to start" error message on that block.   I did discover a small error in the original CAD drawing and corrected that and adjusted the GCode,  but the error still happens.

I am using the SIN, COS and ARCTAN trig functions in Mach to calculate the parameters in the GCode.  When I single step through the code in Mach,  I note that when I come to the part with the three arcs the DRO readings start to deviate from what they should be - based on the co-ordinates from the CAD program (AutoCAD LT) and my checking the calculations with my HP35s calculator.   

Start of first arc
DRO readings          33.1302,30.8210

Start of second arc
DRO readings          34.3560, 31.6840
CAD co-ords            34.3560, 31.6848
HP35s results           34.3560, 31.6848

Start of third arc
DRO readings          40.3720, 28.9010
CAD co-ords            40.3731, 28.9013
HP35s results           40.3731, 28.90136

The next point at the end of the third arc is a hard reference from a fixed point,  so it looks as though Mach is throwing an error with a deviation of 0.0011 in X and 0.0003 in Y at the start position

Am I pushing the accuracy of the Mach trig functions too much?

I've also tried switching between incremental and absolute IJ working,  but with no change.

Any suggestions?

Jim.

MACh3 is known accurate to about 12 points to the right of the decimal. Post your Gcode so we can test it.

(;-) TP

I've attached the file.       It stops at the problem block.

The funny things is that this part is the right hand mirror image and the left hand original one has coded with no problems,  including the slight drafting error.  

The point variables hold the co-ordinates of arc centres of both the right and left hand polygons - #x00 = left hand "X",  #x50 = right hand "X" and #x01 = the "Y" for both sides.   I split the right hand coding out of the left hand coding to try and sort out the error.   This will become a subroutine to generate waterlines round the polygon by varying #600 and #700

Jim.

Isn't it great how you can miss a hash sign on the problem line.   After I posted the last message I decided to have another look at the code and at last saw the missing hash in the "Y" parameter.   I've been missing that all day today and spending hours checking out the original CAD work and double checking figures, 

Jim.