Looking for a working/correct Post Processor for Grbl

[sprior913]

I'm trying to switch to using either Universal Gcode Sender or PicSender to my Grbl based X-Carve CNC.  I have previously been using the Easel customized Post Processor and Easel as my Gcode sender, but I'd like to move on to something more advanced.

I downloaded the generic Grbl Post Processor from the AutoDesk HSM Post Processor library and the gcode is generates is clearly incorrect.  For starters the % line at the beginning and end of the file is not supported by Grbl, nor is the M06 command, and the M30 at the end of the file should really be a M05.  It appears that UGS filters out some of this, but PicSender takes a more pure approach and does not.

So I'm wondering why the HSM supplied Post Processor for Grbl can be in a current state of "couldn't possibly work" and since I know that there are lots of people who are using Fusion 360 with Grbl and either UGS or PicSender, where are they getting a Post Processor that does work?

[daniel_lyall]

They get it from the same places you did or from the default location for posts in fusion there are a number of different GRBL post in there for different flavors of GRBL.

If you have a look at the GRBL wiki it shows what version supports what G and M code, as an example  https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands

[sprior913]

I only saw the one Grbl post processor in the HSM library, so I'm curious where you say there are more of them.

But after doing some more research it seems that for example the M06 command has never been correct for any version of Grbl, it's just that for older version of Grbl (0.8) it was ignored and no error thrown, but still wrong.  Newer versions of Grbl now send an error for an unsupported command, but some Gcode senders (like UGS apparently) have been modified to ignore invalid Gcode errors, but that's just a hack.

So I'm back to why after all this time the Grbl post processor hasn't been corrected to not generated invalid Grbl codes ('%', 'M06', 'M30') in the first place and not depend on the Gcode sender to ignore the error?  It doesn't seem very difficult to change, I'm just trying to figure out how I could possibly be the first person requesting it.

[daniel_lyall]

https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-42F88AD3-150C-4D21-9D97-50357D11904A

[sprior913]

I understood how to find the appropriate Post Processor for whatever machine I'm using, that's not the issue.

What I'm saying is that the post processor for Grbl in both the installed and HSM libraries are incorrect and should be changed.

There are no versions of the Grbl firmware (excluding possibly some derived forks) that actually support Tool Change and therefore the M06 code, yet the Grbl post processor generates them - this is incorrect and should be removed.  The only reason this has ever worked for anyone is that some of the popular Gcode senders have been modified to ignore the error the bad code causes.

Likewise the "%" at the beginning and end of the generated code is also not supported and similarly causes problems and should be removed.

Finally the existing Grbl post processor uses M30 for spindle shutdown at the end of the Gcode - this should be changed to the more correct M05.

These incorrect codes have been causing problems for lots of users with various combinations of Grbl and Gcode senders and should be a pretty brainless fix, but it would be best if the corrected code came from the Autodesk library so ongoing updates won't need to be patched manually by end users.  I don't see any downside to these invalid codes being removed.

The real issue is how to I get the attention of the right people at Autodesk to get this fixed for everyone once and for all.

[daniel_lyall]

So you have tested the other GRBL based controllers' post some put out a tool change some A T or no M and G codes.

If you use the bCNC front end it can do tool changes.

[seth.madore]

@sprior913  can you give examples of other people who are asking for these same things to be fixed? The Post Team certainly is NOT opposed to making improvements so the general population has a solid working post. 

What one may consider "brainless and an easy fix, desired by all", may not necessarily be so...

[sprior913]

Here's the evidence I can provide:

https://github.com/vlachoudis/bCNC/issues/27#issuecomment-100327242

@chamnit M6 is not a supported command of grbl. Other streaming program (UGS for example) simply ignore "error: Unsupported command" from grbl.

https://github.com/vlachoudis/bCNC/issues/27#issuecomment-100330553

Comments from the horses mouth:

https://github.com/gnea/grbl/issues/213

The post processor has been forked to try to address some issues, it would be much better if the Autodesk upstream source was more correct:

https://github.com/Strooom/GRBL-Post-Processor/wiki

Note that one also argues that G28 should be disabled by default.

Here's the response I got from PicSender tech support when I asked them for help:

The "%" character and the "M6" command are both considered illegal commands by GRBL, not PicSender.  PicSender is only reporting the errors that GRBL sends to it when illegal characters/commands are encountered in a gcode file.

An "M30" signals the end of file sending; it does not turn off the spindle.  An "M5" command turns off the spindle.  It is (should be) a function of the gcode generating program (post processor) to add an "M5" at the end of the file to turn off the spindle/laser.  

To test the on/off functions of grbl in the PicSender demo to verify you have the relay wiring correct, you can use the "M03" button to toggle a spindle relay on and off.  When off the button reads "M03" and when on the button reads "M05".

I haven't had a chance to test it yet, but attached is a modified grbl.cps which I think should fix the issues.

---

[sprior913]

I should also mention that all the versions of Universal Gcode Sender I've seen have a built in filter to remove M30 codes (Grbl only recently started supporting that at all), but does not have a M6 filter in place.

I've also seen forum posts where end users have expressed frustration that they never got Fusion 360 working with PicSender (PicSender does not attempt to correct the Gcode or ignore Grbl warnings - they're purists).

I'm actually amazed that so many workarounds have been put in place without actually trying to get the post processor fixed first - that's what I'm trying to accomplish.

[sprior913]

It's entirely possible that where I removed the M6 from the T1 in my modified code, the entire line should have been commented out.

[seth.madore]

What would the desired behavior be when it reaches a tool change? Thus far, I was under the impression that people were posting out single tools, as there was no mechanism for changing tools and starting again.

[sprior913]

Personally I agree with you - I have only ever posted for a single tool so there is no reason for a tool change to exist in the code, but it does anyway.

I am aware that some gcode senders handle this themselves - Carbide Create apparently intercepts the tool change and prompts the user to change the tool then Z probes it and resumes the carve, but the actual tool change gcode never makes it to Grbl where it would throw an error.

But Carbide Create has its own post processor anyway so I would argue that the "pure" Grbl/Grbl post processor should not generate the tool change codes since Grbl doesn't support them, then a derived post processor specific to an environment like Carbide Create would be free to add support for it since it's going to be there Gcode sender which actually handles it anyway.

If you want to take a slightly safer approach I'd say you can leave the option for the Grbl processor to generate the tool change codes, but by default have it disabled.  The only reason I suggest this is that it provides the code as an example for downstream providers (like Carbide Create) to enable it by default since it's supported in their environments.

Make sense?

[sprior913]

Here is the explanation in the bCNC wiki which covers how they attempt to translate the tool change in the Gcode sender (and also note that the option to forward it to Grbl will always result in an error).

Again I argue that since Grbl doesn't actually support it, the gcodes for it should at the very least not be generated by the generic Grbl/Grbl post processor by default.

[sprior913]

I just tested the generated gcode from the corrected grbl.cps that I attached here.  It now works out of the box for both Universal Gcode Sender and PicSender - something the shipping version does not do.

[sprior913]

No comments on this for a week and I'd like to keep this moving - have I sufficiently convinced you and given you enough information to proceed?

[seth.madore]

Thanks for the poke on this. The people I've needed to involve in these changes have been on vacations, so things are starting to settle down. I'll send the info you have provided into them and see what they think. Thanks for bringing all these to our attention!

[seth.madore]

Thanks for all the feedback. I've brought this to the Post team and they will be making the changes to the GRBL post. Look for it in an upcoming update!

[sprior913]

I look forward to it.  In the meantime I noticed that the fork of the grbl post processor that Inventables uses added a nice feature to put the stock block dimensions in a comment.  That's actually a really nice feature to have.  They still do have the issues I opened this issue for, so I created a version of the code which fixes the bad codes and adds the new comment.  I've attached it for consideration.

[Anonymous]

As of last night I too was having the same issues.  By accident I deleted lines 12 and up and ran the program through my universal g code sender with GRBL and it worked.  I used to have no problems with the post process, but that was last year.  Now with the new version the post process does not work with my UGS.  Something changed.  Here are some screen shots.  

post process from 360

[sprior913]

I'm still using the version of the post processor I modified and attached above.  The new version of the post processor released by Autodesk has an option to disable the tool change code, but it defaults to including it.