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
2 Likes
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:
https://my.carbide3d.com/faq/supported-gcodes/
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.
See:
“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.
I guess all those are single line comments and not inline.
That will only stop the tool from locking up when getting a M6 command. You will need to remove any inline comments from the gcode file as well. Essentially you want to make sure the SO5 at no point receives a parentheses.
Removing all of the yellow from the picture below and using the suggested javascript changes is what is needed. I modified my post processor to use semicolons instead of parentheses.
2 Likes
I’ve been smashing my face on just getting the bit setter to work, did you do anything special for yours? New to Tool Change, What's Missing? - ❓ Question - Sienci Community Forum
I use macros for bit setter. From my understanding, the macros I use are a modified version of @neilferreri’s macros which I then further modified to use PRB values for probing and also removed any use of inline comments. You would need to modify the “init” macro to have the correct x and y location of your bit setter if you choose to use the same macros.
My work flow is as follows:
- Set zero by either 3d touch probe or using Vbit and eyes depending on precision needed.
- Run “init” macro to initialize variables.
- Run “probe tool” macro to set initial bit height.
- Run gcode file
- Change tool manually then run “probe tool” macro to offset zero with new bit height.
- Repeat steps 4-5 until done.
bitsetter-macros.zip (1.3 KB)
2 Likes
I was under the impression that, with the right configuration, GSender could do the needful for a BitSetter…
Is that the path you have been down? I had not gotten that far yet.
Ok. I opened an issue/feature request on their github. Feature Request: Suppress gcode comments in gcode sent to machines. · Issue #444 · Sienci-Labs/gsender · GitHub
I can navigate javascript well enough that I can go ahead a create a pull request with the changes you have listed, However a more wholistic solution, as described in the ticket, would be a bit more challenging to implement.
1 Like
Yes. I tried this route first since it was mentioned by a developer as being the integrated way forward for folks like us. But it just hangs. Maybe there’s a comment in there somewhere as it exhibits a similar behavior to using Neil’s default code. I’d love to get it solved in their native newness but I’m not sure that’s possible until someone peeks in and asks for some data for those of us having issues.
Give it a try though and report back. While I don’t want to be the only one having a problem of it works for you maybe I missed something. If it doesn’t at least we are not alone. Heheh.
I’ll try shortly. If it is a gcode problem, that should be viewable in the console. Will see shortly.
That is because they utilize inline comments to send info to the console during the tool change.
Example console output when running on a machine that does not lock up when sent inline comments:
T6(M6)
ok
feeder G4 P0.5
ok
feeder M5
ok
feeder ({"PROBE_THICKNESS_MM":30,"PROBE_DISTANCE":73,"PROBE_FEEDRATE":150,"PROBE_SLOW_FEEDRATE":75,"RETRACT":4,"XPOS":"0.000","YPOS":"0.000","ZPOS":"0.000","PROBE_POS_X":5,"PROBE_POS_Y":20,"PROBE_POS_Z":30,"Z_SAFE_HEIGHT":-10,"UNITS":"G21","SPINDLE":"M5","DISTANCE":"G90","FEEDRATE":"F0"})
ok
feeder G4 P0.5
ok
feeder G91 G21
ok
feeder G53 G0 Z-10
ok
feeder G53 G0 X5 Y20
ok
feeder (Toolchange initiated)
ok
You can find the portion of code that does this in gSender here:
1 Like
ahh its all making sense and all tied to the same issue. Neil had me remove a comment in his bit setter init and viola that works. So now just need to dodge commentary files or run them through some additio
Always glad when you can understand a problem better!