Most design teams aim to produce “intentional products” - products that solve a particular problem for a particular target market in an intentional way. The “test drilling.nc” file posted above is a current output file with the F0 statements which trigger the GRBL error.When you start designing a product, what are your design process and design methodology? How do you know where to start? Image via ITERATE. I also posted a few workaround approaches for people to use whilst there’s no rapids fixer or for those who don’t want to post-edit their g-code with the attendant complexity. It’s easy enough to just search for the “F0” instances in the g-code and just put a non-zero number in until it’s fixed, for the small number of people who even use the drilling toolpaths anyway. I’m also not suggesting that we should confuse this bug with the possible rapids post-processor as this is a bug in Fusion or the Carbide post processor in Fusion, not something we should try to bodge over in the output code. I’m editing the g-code as necessary to run jobs, it was beyond time for me to learn to read and edit g-code anyway, I’ve put it off for too long. There’s no rush from my perspective, other than to document the issue here so that other users aren’t confused if they run into it before Autodesk fixes it, which I’m sure they will, once they’re aware. Thanks Neil for the hints on what’s going on in that code. It doesn’t seem to be affecting any other toolpath either so I’d assume that there’s a poor interaction between GRBL and the additional “no rapids” new code added by Autodesk which there is inadequate test coverage for. On the other hand, if you’re removing or restricting functionality in an update which has already caused a fair amount of negative PR, doing your regression testing properly is expected.

Yep, I’m sure it’s not deliberate, normal developers don’t deliberately break code.

Fusion 360 personal