Problem using Fusion 360 CAM toolpaths with smoothing enabled

I'm running into a problem where a toolpath that should run at a relatively constant feedrate is experiencing unexpected acceleration and deceleration if the toolpath is generated using the Smoothing option, which is a Fusion CAM feature that replaces groups of short G1 line segments in the toolpath with G2/G3 arcs.  I've been in the habit of using this toolpath feature because I'm moving from a GRBL-based controller and using Smoothing was important on Adaptive and other nontrivial toolpaths because GRBL would stall streaming the huge amount of gcode produced with short G1 line segments, but handled a smaller number of G2/G3 arcs just fine.On LinuxCNC, I'm actually seeing the opposite behavior.

I've put together a demonstration of this issue using a spiral toolpath (see SpiralToolpath.png)

I generated the tool path with and without smoothing enabled:
SpiralNoSmoothing.ngc
SpiralWithSmoothing.ngc

When the path without smoothing (just lots of short G1s) is run, the velocity is fairly constant toward the outside of the toolpath (around line 900 in SpiralNoSmoothing.ngc).  See SpiralNoSmoothing-halscope.png.

When the path WITH smoothing (mostly consecutive G3s) is run, the velocity goes up and down each time a new line of gcode is hit - this is especially noticable about 3/4 of the way through the file, around line 100 in SpiralWithSmoothing.ngc.  See SpiralWithSmoothing-halscope.png.

I’ve been using Fusion 360 and smoothed toolpaths for several years now with a grbl controller and I haven’t had any issue with it, but for some reason LinuxCNC is behaving as if each back-to-back G3 isn’t tangent to the previous one, requiring a deceleration between lines of gcode.  But, the same toolpath without arcs is handled a lot better by the trajectory planner.

I need help determine what the problem is here:
- Fusion 360 toolpath generation issue?
- Fusion 360 post processor - using LinuxCNC (EMC2) post version 44083
- LinuxCNC machine configuration issue (ini, hal) ?
- Something weird going on in LinuxCNC’s Trajectory Planner where it’s not recognizing that successive G3 arcs aren't tangent enough to each other that it doesn’t have to slow down ?

In GRBL’s configuration there is a variable called Junction Deviation, which controls how aggressively it will move through line segment junctions. I know that in LinuxCNC this is controlled with G64 P- Q-, But in the example files here I’m using the same G64 P0.005 Q0.005 in both, so this doesn’t explain why LinuxCNC has trouble with the G3-based toolpath but not the G1-based one, even though the paths are essentially identical.

My .hal and .ini files are attached in case that is useful.  In the .ini file, there's a commented out HALFILE line that you can switch to use the attached "sim" file which can be used to simulate the machine and the issue.

Dan
 

OK So I'll remove the first bit where I thought it was missing G2/G3 arcs, since it does have the arcs I just had searched only for G2 at first.

There are some postprocessor settings you can play around with in Fusion, but it appears you've already done this (I had a similar problem but apparently the postprocessor default was not to generate arcs with LinuxCNC Postprocessor)

I'll do some more thinking ...

Is there anyone here that is familiar with LinuxCNC's Trajectory Planner  that could suggest further steps to debug why the TP is slowing down between these arc segments?  I do see that there's some debugging output in tp.c, but it looks like I probably have to build LinuxCNC from source with TP_DEBUG defined in order to see it.  I also don't know if that will actually give me any more information here.

One thing I did try was to hand-write a gcode file with a series of circular G2 paths that had different center points but were otherwise tangent between them, and with G64 P0 Q0 it behaved as expected - it followed the path exactly, and it didn't slow down between arc segments, so I think this probably has to do with Fusion 360s smoothed series of arc segments not being tangent to each other... but I would assume that increasing the path following tolerance with G64 P0.010 Q0.010 or even G64 P0.1 Q0.1 would allow it to round off the junctions between the arcs and keep the speed up, but it doesn't seem to be doing that when I've tried it.

I know I'm not adding a ton to this, but I do have the videos from where I experienced a similar problem.

(Link to the videos on Imgur - imgur.com/a/2GQUPrA)

When I look back through my history of trying to resolve this with some others, I never did track down the source of the weird behavior, but when I rebuilt the CAM using FreeCAD Path instead of Fusion, it generated without these issues and cut smoothly.

In the end I attributed this to some weird Fusion issue instead of LinuxCNC.

I wonder if the arcs are read as offset slightly by LinuxCNC because under Fusion's post-processor they're under some tolerance but in LinuxCNC they're not, and the trapezoidal TP in LinuxCNC chokes on these? forum.linuxcnc.org/10-advanced-configura...7-smoothness-of-arcs