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)
G90
G17
G20
G28 G91 Z0
G90
(<Toolpath 1 name>)
<if changing a tool for the next op, add the following 4 lines>
G17
M5
G28 G91 Z0
G90
(Toolpath 2 name)
<<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:
- 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 - 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.
Thoughts?
