Fusion 360 Post processors without tool change G-code output.
The only difference should be that the ones from Autodesk should output T1M6 lines and the other two should not.
Autodesk
carvey.cps (18.7 KB)
xcarve.cps (18.7 KB)
No tool change.
carvey_no_tool_change.cps (18.7 KB)
xcarve_no_tool_change.cps (18.7 KB)
@LarryM I was looking at a different PP. I used the one I found here:
https://inventables.desk.com/customer/portal/articles/2332499?b_id=9563
It’s been a long time since I put the PP on the forum.
Someone was having a problem with a Carvey and this fixed it so I just did one for the X-carve while I was messing with it.
Bottom line is if you have one that works, stick with it.
Can you explain in what situation the tool change line causes problems?
Also, is this post processor the one to use if you’re using Easel as a gcode sender or does it generate codes Easel doesn’t support?
Grbl will ignore the T1 command, but the M6 will cause grbl to alarm and halt.
That I can’t answer. I was just looking into the tool change problem at the time I took a look at their PP. I do know that Easel will not pass arc commands (G2/G3).
Easel does not send the M6. If it did, grbl would return an error.
It just skips them. I just did some tests with the f360-easel.cps post processor that I downloaded from Inventables found on the linked source above.
I think the problem would be if you were expecting the machine to pause for a tool change because you needed to change tools. Easel does not handle/manage tool changes in imported gcode.
That would be Easel’s job. There are so many ways to handle tool changes, it is probably easier to let that fall on the sender. Maybe there will be some implementation when the new, Arm based version of grbl is released.
I meant it would be the job of the sender. In your example, UGS, would process the M6 and send a command to the controller.
CNCjs does this and so does bcnc.
I guess I have a different point of view here.
The sender should not manipulate the G-code file as it passes through the sender. The sender should send the file as is and report back any errors that Grbl sends it.
There are two G-code standards that grbl uses to determine how each G-code command should be handled. Grbl should control the interpretation of the G-code commands as specified.
In this particular case grbl does not support the M6 command, so it returns an invalid G-code error when the sender sends M6. The sender should report the error back to the user, not assume that the user just wants to throw it away.
I didn’t have two cents, so I gave one.
My cent:
Tool changes are beyond the scope of grbl, but a GUI can be designed to handle one in any number of ways. Inventables could release an auto tool changer add on for the X-carve, and they would not have to create a new controller or even modify the firmware. It could all be handled in Easel.
That said, I agree with you that the sender should not just ignore tool change commands as Easel seems to.
I use CNCjs, and I am prompted by the GUI on a tool change. I can run a macro to change the tool, re-zero or set a tool length offset (which grbl supports), and continue the job.
A pause is a different command. You could change your post processor to do that.
There are too many variations in machines, using the same standard gcode, for grbl to include all possibilities and all possible user preferences. Why is a pause better than an option to run a macro or use an automatic tool changer? What if my spindle is in the middle back when it gets to a tool change?
We may disagree here, but I think it makes sense for that all to be left to the GUI. If one wants to send the M6, receive an error, and stop the job, there’s a UI that will do that well. If one wants to be prompted to make decisions for the machine, there are GUIs for that. If you have the machine for it, and you want the machine to change tools for you while you eat a taco, I’m glad you have that option.
Grbl handles arcs, Easel (the GUI) does not.
As long as my GUI can intercept that and do what I want with it, I’m game.
My view is that grbl shouldn’t need to get to that point. There is more processing power and easier configurability (word?) at the UI level.
Not quite a copy/paste, but as close as you wanna get.
It’s all software. Possibilities are endless. Your method of operation seems to be more in line with Mach3 than grbl.
