I had a look at an open source add-in https://github.com/TimPaterson/Fusion360-Batch-Post and regarding the rapids it seems to do a post-post-process – ie loads and analyses the post processed g-code.
I decided to have a look at the Tormach milling post-processor and have added a simple patch to put at least some of the rapid Z moves back. It seems F360 milling toolpaths often start with a rapid X/Y move, followed by two rapid Z moves, then goes into the cutting. So if my patch sees a Z move that goes to above 0 (ie above the stock when the top of stock = 0) it emits a G0 rather than G1.
This restores rapids to the start and end of a toolpath, and also on the way up after a cutting pass when doing multiple depths.
This might not go well for you if you don't have +Z above your stock, or don't get toolpaths similar mine!
function onLinear(_x, _y, _z, feed) {
// existing post-processor code
var x = xOutput.format(_x);
var y = yOutput.format(_y);
var z = zOutput.format(_z);
var f = feedOutput.format(feed);
// use rapids for Z movement to Z > 0 and no X/Y
if (_z > 0 && ! (x || y)) {
writeBlock(gMotionModal.format(0), x, y, z, "(Assumed rapid)";
feedOutput.reset();
return;
}
// existing post-processor code
if (x || y || z) {
…
Edited By David Taylor on 01/12/2020 03:53:26
Edited By David Taylor on 01/12/2020 03:54:00