Preventing Fusion from Generating Invalid Tool Change Commands

After an XL expansion my first project was to do the XL version of the Winston wasteboard that I have been using for a while on the S3. Not much of a Fusion 360 person and every time I tried to run the toolpaths they errored-out and locked the machine.

Turns out it was because Autodesk is inserting a tool change command “T1 M6” at the front of the file. This happens with both the Carbide and generic grpl generators. When I edit out the command it seems to work fine (just air carving until I get this debugged).

I don’t so any simple way to turn this off and I see a lot of complaints about the complexity of customizing the post processors.

I assume this is a well known issue? Any easy solution?

Hmmm, sorry I don’t have an answer, need to do a little digging.

All I can say is that I use F360 exclusively and have never seen that particular error. I’ve had troubles with arc errors, CM ..411 has fixed that but unrelated to what you are seeing.

My controller is the Sparkfun version but I would think this would be a software issue.

I use Fusion a lot and I will check tonight to see some random samples of the G-code it generates and see if I have the same lines. I have not seen the Tool Change error once, but like @Griff, I’ve had the arc endpoint error a few times but 411 fixed this as well.

I would be curious if you have more than one toolpath post processed into one G-code file. That is one thing I have not done; I always use one toolpath per file. For me, even if a mill change is not required, it doesn’t bother me to have one file per toolpath and it makes error tracing easier.

I’m also on the single tool path per file bandwagon Evan mentions.

I’ve now looked at a number of my Fusion generated g code files and not seen what you’ve described.

1 Like

Hmmm - I’ve done multi toolpath operations with tool changes out of Fusion360 and not had that problem. Suggest posting the output log from CM and your gcode as generated by F360 - someone will probably want a look at it.

All of my Fusion-generated gcode files have T1 M6 at the start. I use the Carbide3D post processor. I’ve run jobs through Carbide Motion (grbl 0.9) and Grbl-Panel without any errors on a standard S03/XXL.

1 Like

I am working with the following public design file:

Even if I do the paths “individually” (i.e. right click and generate path/post each one) the files have the T1 M6 at the start.

I agree that the rest of the toolchain is partially to blame. It’s UGS (latest stable “platform” version) that says it is stopping because of the controller receiving a bad command. Since there are a couple of “Coolant Off” commands in the same location its not clear why grbl <> UGS is picking on the tool change command. You’d think it would just ignore it.

At one point a dialog popped up and UGS offered to ignore an error but that didn’t solve the problem.

I can hand edit the files. Just afraid I might miss something.

What version of post processor did you use. I recall seeing some options in post processing for tool changes but could be wrong, just have a dig around in the post processing options screen where you click save. Are there different tools embedded into the post or just one tool for the whole operation?

Just one tool for the whole operation. If you mean the settings that come-up in the lower right of the Post screen, I have reviewed them and see nothing about tool changing. I did not go as far as editing the post processor which I am shying away from given the feedback that I’ve seen.

Having produced the wasteboard using hand editing of the gcode I am going to return to vcarve.