Nope, just drew it, chose profile and "on-line" offset then output the code.
Printable View
Try drawing another circle and doing the same.
As I said, in your file, if I draw another circle it works, but your circle doesn't.
Still messing with this.
Just imported the same file - a single 19mm circle, drawn in my CAD program, into SheetCam and Aspire. Used the same tool, same profile type, single pass cut, outside edge.
Sheet cam seems to make the hole in one go...
N0110 S24000 M03
N0120 G00 X9.5000 Y-1.0000
N0130 Z1.0000
N0140 G01 Z0.000 F250.0
N0150 G02 X17.2584 Y2.4249 Z-3.0000 I0.0000 J10.5000
N0160 X17.2584 Y2.4249 I-7.7584 J7.0751 F487.0
N0170 G00 Z20.0000
N0180 X0.0000 Y0.0000
N0190 M09 (Coolant off)
N0200 M05
And Aspire seems to do a circle in four arcs?...
N130 S24000 M03
N140 (Toolpath:- Profile 1)
N150 ()
N160 G94
N170 X0.000 Y0.000 F377.0
N180 G00 X0.000 Y10.490 Z20.000
N190 G00 X0.000 Y10.490 Z2.000
N200 G01 X0.000 Y10.490 Z-5.100 F377.0
N210 G02 X10.490 Y0.000 I0.000 J-10.490
N220 G02 X0.000 Y-10.490 I-10.490 J0.000
N230 G02 X-10.490 Y0.000 I0.000 J10.490
N240 G02 X0.000 Y10.490 I10.490 J0.000
N250 G00 X0.000 Y10.490 Z20.000
N260 G00 Z20.000
N270 G00 X0.000 Y0.000
N280 M05
Any further ideas?
The posts for aspire all have ARCS in the names, using a non ARC post generates thousands of very short lines for a circle.
Does it matter whether it uses one line or 4 quadrants ?
post processed literally 1,000's of programs thru Vectric with no hickups
I believe that Aspire always does circles as 4 arcs.
Slightly different cutting strategies. Aspire plunges vertically, then cuts the circle in 4 arcs. Sheetcam ramps down in one partial arc, then completes the circle at constant depth (I think - haven't decoded all the coordinates). There also appears to be a 0.05 difference in radius. But I wouldn't worry about the 1 arc/4 arcs difference - in practice, Mach3 is going to optimise its cutting strategy based on looking ahead at a group of moves and the machine parameters and I doubt if it cares!
Doesn't really matter of course, i just like to know whats going on thats all :)
Sometimes Aspire seems to resort to making curves from many lines and these were visible in the finish, especially if feed rate override was in use.
Not sure what you are saying here. If Aspire generated code with arcs then you turned the federate up in Mach3 that could not change it into small lines.Quote:
Sometimes Aspire seems to resort to making curves from many lines and these were visible in the finish, especially if feed rate override was in use.
I think there is a setting in Mach3 CV that can be ticked.
I'm guessing a bit here, but one reason for Aspire's 4-arc strategy might be potential problems with motion controllers. I seem to remember a gcode manual mentioning that some motion controllers could get a bit confused by full turns, so breaking it into arcs could be more reliable. If that was true once, it's probably not relevant any more with the motion controllers we use today but maybe it's just a historical thing?
There's a discussion of a possible reason here, to do with rounding errors in start/stop points in nearly-full circles. I used to use a free CAM package with LinuxCNC and it often threw up errors with these kind of arc calculations in g2/g3 moves. When I moved to vCarve all those problems went away, so maybe there's sense in it!
Interesting.
The one time i noticed it, i was doing a dummy run so had the feedrate turned up to max, it was very jerky on curves, thats what made me think.
I will need to do some more observing but at least i know now its probably just normal :)