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!
Confirmed just tried to run the BitSetter…choke. Guess I need to check out that macro. Also, I have a BitZeroV2, that is now working since I was sent a new front panel board. Has anyone successfully gotten probing to work with it? I would be good with treating it like a standard probe without a hole, but the routine has to move far enough to avoid the loop.
Well this isn’t good. Some garbage showing up in the traffic logs now. And the machine doesn’t want to jog. It does however initialize, and probe the bit…with CM that is. It will home and jog with GSender…it seems to have hosed CM somehow. Tried CM on another computer, ran through the setup wizard, and resent configuration to the machine. Jogging, homing, all that seem to work. However, the machine is cutting like garbage. I have some round countersink holes I am cutting and it seems to be stuttering on each of the small line segments that make up the circles. It’s as if banter to and from the machine, like baud rate has dropped to next to nothing or response latency has went way up.
I’m thinking the firmware on that esp chip got corrupted somehow and that I need to reflash firmware. I capture video, but it seems I can’t upload here.
Edit: the stuttering might be from having the log open as per Weird stuttering in corners S5 Pro - #3 by CthulhuLabs
@gsrunion Can’t assume. Have you powered down the machine completely? I cant think of a way you could’ve corrupted any firmware simply by connecting to another sender.