GSender, any special steps to use?

I tried to use gsender to night for the first time. I load my gcode, after creating zeros in workspace 1 and 2, and click run (in workspace 1). It displays some prompts about a bitsetter, which I had setup when my front panel board was working, and I realized I needed to turn that off. I abort the job and go into settings configuring tool change to be ignored. I then go restart the job, and after just a few lines of code sending things stop. I go look in the console and there is no dialog between the machine and gsender but it acts like things are in progress (but not updating).

Is there any extra bit of configuration I need to do in gsender to make it work in this scenario? Did I do anything obvious wrong?

yet again (243.7 KB)

Are you using a SO5? If so then you can read about the issue and how to fix here:

100% that is the problem. I known what I am working with now, thanks.

I’ll see if I can’t put up a pull request for the gsender folks to merge in.

1 Like

I don’t know what that means, but the gSender forum is here.

It’s really something that should be changed in the firmware as all grbl-based machines that I’ve used can handle it.

I thought that C3D said a while ago that post processors would become accessible for Create. This would be another way to fix it if they do.

If someone w/ a current Pro license wants something specific for a post-processor, let us know at

@WillAdams even those without pro licenses can output gcode via the converter on the website. Does postprocessor selection affect the gcode of embedded in the C3D file?

I believe the exporter assumes “Carbide 3D Shapeoko/Nomad” and given its purpose, I can’t see a reason for it to do aught else.

A quick test would indicate that is true. A C3D file saved with different selected post processors seems to output the same gcode once converted and diffed.

Software development term. Since gsender is open source, with their code sitting out in github, I can fork their code, make changes, and request that they incorporate my changes.

But should you? Should they incorporate it if you do?

If a valid gcode file crashes the CNC, that’s a firmware bug which sounds insane that it hasn’t been fixed yet ← @WillAdams


There is a limited number of G-code commands which Grbl understands. Sending valid G-code other than that has been noted to cause odd behavior in the past (I believe Carbide Motion will strip any such out)

Carbide Motion adds a few more by either managing machine movement so as to implement them, or filtering them out.

Grbl also has a limited line length (but I believe the one program which ran into that is no longer prevalent).

For further details see:

If using a 3rd party tool, I’d suggest checking in w/ the Grbl folks — they seem to have pretty thoroughly covered this sort of thing in the past.

Agree that this is not a sender side problem and that C3D should fix in the firmware. What I am unsure of is that the Shapeoko firmware is supposed to be a minor fork of grbl and if grbl had this issue it would be more generally known.

As far as to whether it should be also addressed on the GSender side…There is no, AFAIK, functional reason to send gcode comments to the machine. Comments are for human readability and machines are not going to do anything with it. As such, doing so is neither of value and a place for problems to occur. As such I think it would be pragmatic to remove.

I went and looked in the grbl github last night. I saw no issues, open or closed, that have to do with inline comments. That would suggest the S5 flavor of grbl is doing something there. I saw the source for the S5 grbl variant somewhere, let me see if I can find again and have a look.

My understanding is that Carbide Motion strips out comments and because of that there wasn’t much testing done with them, and that there is a problem with them in Grbl on an SO5 Pro.


“Regarding the parenthetical comments, that’s not a thing in GRBL, it’s in the USB chip we use. We don’t test our machines with other senders, so it’s not a code path that got tested. The next time we’re in that code, we’ll take a look at it.”

Interesting…in the usb chip. That might be a tougher fix.

1 Like

That would sure be surprising… The USB chip shouldn’t be parsing the data, just passing it along!

By USB chip they mean ESP32 as that is how they are using it. Most likely a bad USB protocol implementation.

1 Like

@Gibs SO5 Pro inline comment firmware issue - #3 by Gibs are the suggested javascript changes there enough? Does gsender already suppress comments going to the machine? My gcode file attached has plenty of parens outside of the tool change context.