Printable View
Been learning Aspire for some CAM work, it seems to have a bug with simple circles where it generates G-Code with hundreds of straight lines?
Here is a simple test file - it contains two paths, first is a square with 10mm radiused corners which works perfectly. The second is a simple circle and as you can see it has used loads of straight lines this time.
Attachment 18868
Can this be fixed at all, I am using the post for Mach3 with Arcs and ATC.
Thanks
Dave can you post the Aspire file up?
I have just drawn a simple circle in Aspire and put it through the MAch3 post without any problems.
Have you done the cad in Aspire or imported from another cad package there is a command to close vectors with a smooth curve
Daft question, maybe, but did you draw the circle in Aspire or import a dxf from elsewhere? I had similar problems a little while ago because I had saved the dxf in the wrong version so it ended up as a series of line segments rather than arcs.
Hi
the file was just a quick mess about for testing the motion on my mill conversion project.
It was all done inside Aspire.
File attached
Attachment 18869
I just made a similar file in my CAD app and converted it in Aspire and its just as bad, converted in SheetCam and its perfect - about 15 lines of code :)
Seems to be an aspire bug?
Dave when I draw a circle in my Aspire it is fine when I did another circle on your drawing it is also fine. Did you draw the circle in AspireQuote:
Originally Posted by Davek0974
The post I am using is Mach2_3_Arcs_mm.pp
Yes i drew it in aspire, same post here although i tweaked it a little to suit my machine but only in the end code i think.
Aspire does the same thing when i import a circle from my CAD app.
I'm not familiar with Aspire but most CAM applications have an option for lines or arcs as some old controllers don't support arcs.
If you select a "lines, not arcs" output option in CAM the results are as described,
- Nick
On reading further. I have read that if you stretch a circle in Aspire it changes to segmented lines.Quote:
Originally Posted by Davek0974
You must have modified the circle in some way.
If I export g-code for your circle, it uses G1 segment.
If I draw a new circle over the top of your, and export g-code, I get G2/G3 moves.
Quote:
Originally Posted by Ger21
Nope, just drew it, chose profile and "on-line" offset then output the code.
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 :)
This is a known issue with Mach3 and Feedrate Override. It works fine when below 100%. but it can cause jerky movement when turned up a lot above 100%.Quote:
Originally Posted by Davek0974
I don't recall if there's a safe max to use, but I would keep it below 125%.
Excellent, i like known issues :)
At least there is a reason.
Thanks
I ran a couple of parts earlier this week using Mach3 at 300% without noticeable jerkiness on the curves.
Different versions have different issues, mine doesn't seem to have jerky curves above 100% feedrate, I'll check the version but it's the one most recommended for general use on the Mach3 forum,
- Nick
I think that the issue is PC dependent, and doesn't affect everyone. But it is an issue, and was confirmed by Art, the author of Mach3.
The Machsupport forum is down right now, but I'll try to find some more info when it's back up.
Does using a external motion controller make any difference - is the jerking only when using parallel port?
Why do you use FRO at 300%?
Program the feed closer and just go up to 70 or 80%.
Most professional controllers won't allow more than 100%
This is with a motion controller, UC100
As i said, i was only doing a dry run so speed was irrelevant, in reality I have never used FRO or SSO !
I would normally adjust feed rate to the middle of the green in CAM but it was a one-off job profiling a couple of small ally plates with a new single flute cutter, I realised it could run faster once I started the job so I just wound it up until it felt right rather than going back to CAM.Quote:
Originally Posted by John S
- Nick
Is the Mach forum having issues - i have not been able to load it since early yesterday morning???
Yes, I mentioned it in my previous post.