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?
@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?
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.
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).
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.
@GibsSO5 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.