Just a heads up. At my request Autodesk just updated their GRBL post processor to stop generating gcodes which are actually not supported by GRBL. I haven’t actually switched to their new code yet because I had already patched my copy, but anyone using Universal Gcode Sender, PicSender, or any other Gcode sender which does not filter out invalid codes should see improved compatibility with the new version here.
@JeffTalbot This should also be looked at because the Inventables Easel post processor for Fusion is derived from the Autodesk one and also includes invalid codes like T0 M6 (which was NEVER supported by GRBL) and you should probably change that.
1 Like
Other than the M6, what else is omitted?
True, but it is a consistent standard for tool changes that could be handled by grbl senders.
I don’t use Easel, but doesn’t it use the M6?
You don’t have a use for tool changes?
I’ve just reviewed the new post processor code and it’s a little better, but not perfect. They added a new option to control the output of the unsupported tool change gcode: “Output tool number” but unfortunately defaults to true when it should be false.
They did stop outputting the unsupported “%” lines which is an improvement.
The last issue is that they still output M30 to stop the spindle at the end of a carve. With recent versions of GRBL this is technically correct and will work but wasn’t supported until recently so some Gcode senders (Like UGS) filter it out as a workaround. This means that your spindle will not automatically shut off at the end of a carve. I had suggested they use M5 instead while will work and not be filtered out. Since this M30 code is now supported the real right thing to do would be for UGS (and any other sender) to stop filtering it out when a newer version of GRBL is detected, but that’s going to cause confusion.
My opinion is that a code that causes an error in GRBL should not be output by default by a post processor that says it’s for GRBL. If someone uses a “pure” gcode sender which does not filter out an invalid code (UGS and PicSender do not filter out M6) then users of those senders will get errors. If someone is using a Gcode sender with enhanced function to handle tool changes that’s great and there can be an option to include them, but it should not be the default.
1 Like
One reason this was not as much of an issue before GRBL 1.0 is that earlier versions of GRBL simply ignored invalid codes. This is no longer the case and newer versions throw an error. So we got here by the post processor always using unsupported codes and the firmware ignoring them, but now things stopped working for gcode senders which simply send the gcode without filtering it.
I will mention that the PicSender folks were not helpful in figuring out this mess because their response was simply “your post processor is outputting invalid gcodes” and then when asked how people are using Fusion 360 with PicSender the response was “we don’t use Fusion 360”.
I also use a custom post, but I’m still glad they didn’t get rid of the option for tool changes.
Successful tool changes bring me joy. 
I think there should be an option for tool changes, just that it shouldn’t by default be enabled - if you have a gcode sender with enhanced function to support them then you should be able to turn them on. Of if you’re deriving a custom post processor for your machine and your official gcode sender supports them then you can make it default to on in your version. But the generic post processor shouldn’t crash the generic setup of the firmware.
The problem comes with jobs that require a tool change. If that isn’t there, your job could go straight from a facing operation with a one inch mill to the engraving op that calls for a 90deg chamfer mill. Could be a disaster to v-carve with a one inch face mill.
No matter what, people are going to find ways to jack something up. Hopefully they’ll learn from those situations.
Thanks for sharing this info about the update.
If your gcode sender adds extra function beyond the default provided by the GRBL firmware you can publish a custom post processor that enables it by default or users can enable that support once and leave it on and never think about it again and it’ll just work. But when someone uses one of the gcode senders which does no such post processing and uses the generic post processor for GRBL and gets an error that’s not a good thing. And keep in mind that until I requested the change there wasn’t even an option to turn that tool change code off at all - you had to modify the post processor code to do it which lots of non programmers are not comfortable with.
Here is what happened to me (and I’m a programmer):
- I had been using Easel as my Gcode sender which was working, but I wanted more features
- Lots of folks recommended both UGS and PicSender
- Both of those programs flagged an error when I tried to send gcode generated by both the Easel and generic GRBL post processors.
- At that point I’m wondering how this is possible, I’m certainly not the first person doing this.
- The PicSender folks told me that my post processor was at fault because it was generating unsupported codes - and I then confirmed they were right.
- I modify the post processor myself and get it working and wonder why the heck I needed to do this just to get things working. I see forum comments that others never did. I see posts by the author of UGS that they had worked around some of these invalid codes (but not others). How did we get to where people worked around something without asking the original source of the post processor to fix it.
- I asked Autodesk to fix it, and they did make some fixes.
