Writing a supplementary post-processor to fix the fusion rapid problem

TLDR: the fusion 360 changes are a bummer but we could probably post-process our gcode into something usable without pain. We would need a little community help to make it happen: details below

The fusion 360 license changes have me as much as everyone else - especially the concerns about this behavior happening in the future.

That said, I think that these changes only have two negative impacts on my personal experience:

-Loss of rapid retracts
-Loss of automatic tool changes

I propose that we write a simple script to post-process our G-code to fix these issues:

NOTE: I AM NOT A G-CODE EXPERT (but this looks easy)

Right now, the overwhelming majority of rapid retracts are immediately preceded by a G1~G4 command with absolute positions for the tool to be interpolated between (almost always G1). It would not be hard to identify any G1 movements which move the tool directly up and replace them with the appropriate G0 command. The difficulty of this post-processor depends on the exact way that the rapid retract change is implemented in gcode.

Likewise, the loss of ATC is also easily overcome. All fusion 360 *.nc files (as post-processed for carbide3d) look about the same to me:

<<BEGIN *.nc FILE>>
(T1 <Tool 1 info>)
(T2 <Tool 2 info>)

(TN <Tool N info)

G28 G91 Z0

(<Toolpath 1 name>)

<if changing a tool for the next op, add the following 4 lines>
G28 G91 Z0

(Toolpath 2 name)

G17 G28 G91 Z0 G90 G28 G91 X0 Y0 G90 M30 %

<<END *.nc FILE>>

Imagine that we post process a setup into a number of *.nc files, for instance one per endmill. We then feed all of these *.nc files to a simple script which extracts the toolpaths, and sandwiches them with the code for a toolchange, when needed. At the beginning and end, we stuff in the appropriate header and footer respectively.

At this point, all that is needed is for the tool to know what order to process the files in, and what tools to request at each step. You can encode this in the toolpath names if you wish, or in the filenames of the post-processed *.nc files.

There are a few possible gotchas in this code: The logic for determining when to add a rapid retract would (if naive) assume that a positive Z value would indicate a tool position which is higher in elevation. I don’t know if there is a redefinition of planes or axes which could make this assumption invalid.

In order to do a good job at this, we will likely need to collect several instances of post-processed files before the october-1 changeover. These files will then be compared to their equivalent files after the october-1 changeover in order to confirm that the conversion script is correct. A small community effort could likely produce a database of 20-30 projects for this effort, which would greatly facilitate the automated testing of the tool.

If we were to do that, we would need two kinds of files:

  1. files containing only one tool (to test the script which restores rapid retract)
    1a. There would need to be a special emphasis on getting a variety of toolpath settings and setup settings to ensure that we produce a script which performs well in all cases
  2. scripts containing entire setups with multiple tool changes. These would be used to test the toolpath merging routine

All in all, sounds like two hours of work for a basic python script, possibly a bit more to get something that a non-programmer can easily use. I’m down if the community is so inclined.

There would also be a concern regarding legal liability. I would be hesitant to release a tool like what I just described, given that mistakes coding could result in unexpected toolpaths, damaged hardware, fires, that kind of thing. I’m sure that carefully worded warning messages and a conversation with legal could address this.



It’s definitely worth exploring.

Some of us are likely to end up paying for a subscription too on the basis that we use the tool enough for it to be reasonable for us to pay. ( so there’ll be opportunity for ongoing comparison )

My main concern would be the support load it would almost inevitably generate as users not familiar with running home brew or open source code used it on their GCode and ran into issues. If the loss of rapids is anywhere near as irritating as I expect it to be there will be quite a bit of demand and therefore quite a few issues.

1 Like

re: support - It’s going to be super annoying, and I’m afraid that I won’t have time to properly support such a tool beyond some “here’s how to use it” video tutorials and the such. This supplementary post-processor is definitely not an ideal solution :stuck_out_tongue:

re: subscriptions - That’s a good point. I suppose we don’t have to rush to get a dataset of gcode if there will be several members of the community who can provide test routines.

I’m most worried about some unsupported setup causing crashes, tool breakage etc.


Very easy to build and simpler than the other gcode tools I’ve build… if there is interest I can likely build something like this in about an hour or so


I’ve written and operated quite a bit of Python, so if it ends up as Python then I can help out with questions about running it, Python environments on Windows / OSX etc.

1 Like

Count me in for beta testing (there is no question that there will be interest, lots of it).

If the Autodesk folks don’t change their mind (as they did on STEP export), I’m sure we’ll see TENS of similar scripts being created all over the globe, but there is value in having one that is known to work with files generated using the Shapeoko post-processor.

To be honest I already pictured this as one of the cool JS apps that @fenrus does, a simple page with a button to upload a set of files, that would spit out one file with tool change commands and rapids. A large “use at your own risk blablabla” disclaimer, done.

The really interesting part will indeed be the validation of that code across a large dataset. I foresee some maintenance effort too, whenever the Fusion360 folks will change their post-processing back-end to “clarify” things further, and it happens to break the application in the process.


I’m happy to help with any beta testing as well.

From the perspective of a non-nerd (said with all respect), I just need something that works, if it can be done wrong I’ll find a way type of user.


Many moons ago, I got really irritated that plunges from CC were emitted without rapid to a safe height (the previous Z) and plunge from there. So I set out to over engineer the problem. A lot. I wanted to try some Swift, and came up with a few things to otherwise optimize while I was at it (including implementing “/” and lay the groundwork for some better reordering to minimize rapids…the old traveling salesman problem)

I’m not going to claim this code is right, or useful, an even moderately poor example of swift code or even very helpful, but it’s here if someone has a want. I haven’t touched it in 4+ years.


at this point I have a lot of this kind of stuff as helper libraries in C++ and Javascript… porting also to python shouldn’t be insane since it seems that’s what folks want.

as part of a gcode optimizer I also have the library functions built that track the cutter engagement for a path (based on previous G1) so conceptually using G0 if the engagement is 0.00 is quite in the realm of possible…

… or if there is a “go up, move, go down” pattern, change the amount of up to the level just above where engagement becomes non-zero

I think I’m the one who kicked off the python thing, but it’s just the hammer I have- another language is fine, I just won’t be as effective for helping develop. At the end of the day we’re all just into it to make the problem go away

@julien a JS app is long term totally the way to go-upload a few nc files and just download the corrected result. In any case it looks like fernus is pretty experienced at this so that’s a fantastic starting point

I’m going to collect a few dozen projects off of Winston’s patreon as test input, plus make a few test programs that are more likely to cause trouble. I’ll share that work after getting permission from Winston for his work.

@griff we’re a group of people who make programs from 3D models to move a drill around and cut cool shapes in wood. If that doesn’t make us all nerds I don’t know what would :stuck_out_tongue_closed_eyes:



is likely where I’d start using the base functions from that…

(https://github.com/fenrus75/FenrusCNCtools <-- github location of this stuff)


Awesome, thanks. I just skimmed it but that’s some pretty cool stuff and unequivocally more sophisticated than what I had in mind :wink:

I’ve made the pre-october1 dataset so now it’s just a waiting game to see what their changes look like in gcode.

1 Like

I am up for beta testing too. I would also contribute to a kickstarter if we need any funding.

Changes went into effect today guys.

I have a paid and free subscription so I can share posted g code for both. What do we need to really get this ball rolling?

I would love to have some relatively simple design create gcode that shows the problems…
(a 5 megabyte gcode file is less useful there than a relatively simple one)

Thats strange, I just checked with some test pieces and they had no difference in posted gcode (as tested by diffchecker - also saw some G0’s floating around in there)

EDIT: just kidding! I changed a few parameters in my test design back and forth and now we’re posting bad gcode.

The attached gcode is a simple test file I put together for this purpose. The model (see: dropbox link) is a box with a cutout and a joined sphere in the interior. I apply a number of redundant adaptive and pocket operations with a few different settings to it in order to exercise the full extent of badness that we could have reasonably expected fusion 360 to have thrown at us before having seen it.

It looks like at the start of each toolpath, F360 does the following
G0 {entry point}
G1 {clearance height}
{retract height}
{feed height}
{normal toolpath stuff}

We can use this to identify the clearance, retract and feed height for the toolpath, and then just keep track of where F360 moves to, changing toolpaths as needed.

online diff (very long!) https://www.diffchecker.com/LhP7iFmy
.f3d file (it’s probably awful) https://www.dropbox.com/s/svcvxzvkjvpo8cb/testSphereForFusionLimitations%20v3.f3d?dl=0

testPieceBad.nc.nc (588.7 KB)
testPiece.nc.nc (588.3 KB)

back to work for now, but I’ll get started tonight or tomorrow morning


My paid license updated and required a restart but the free personal has not and is still posting tool changes and rapids

I am not into writing scripts, so I don’t know if this is useful. but it is something I stumbled upon while looking for a solution for another problem* I have:

And from the ‘Manual’ button:

This may not apply so I apologize if it doesn’t contribute to the solution…

*For the curious, the problem I am researching and trying to solve has nothing to do with scripting to replace or re-enable the rapids, but instead with exporting operation ‘edit’ parameters, specifically I would like to output all parameters and current values for a given operation to a spreadsheet for archiving/comparison. Basically everything that is enterable in the multi-page windowlet when you go to edit an operation, I want to output all of those things to a spreadsheet…

1 Like

I started a new thread for work in progress for the tool

@rmonroe your files have been extremely helpful already so thanks a lot for providing them

1 Like

No prob! switching over to the other thread with my first draft of the script and comments therein