Question: I just updated to 1.2.2 late last week and trying to track down some issues. I was getting random pauses i some files and I just noticed one something that definitely causes a pause. I updated my post processor for Aspire and if I include the tool name in the gcode file, gSender will pause with an error due to the tool name format.
Tool name:
Tool name example: “HOG Roughing End Mill (1/4”) UP CUT "
Tool Diameter: 6.350mm (grbl metric pp)
Post Processor line to add tool name and diameter: “(Tool: [TOOLNAME] - [TDIA])”
Output in gcode:
(VECTRIC POST REVISION)
(65E94BC83A77B1EB83DAC749F0EEAA6B)
(Tool: HOG Roughing End Mill (1/4") UP CUT - 6.350)
T1
G17
G21
G90
…
I’ve attached the error that shows in gSender. The job will move to position and then pause. I can resume and it runs ok. I’ve checked and I am ignoring errors and any tool change commands.
If I change the tool name to remove the additional parenthesis, the gcode works fine.
Here is the gcode compare of the working (left) and not working file (right) “working” is relative because it will continue after hitting resume. Even setting gSender to ignore tool changes, it still pauses which appears to be what happens if there is an error encountered
This isn’t about problems before/after pausing. This is related to how gSender parses the file and how it handles lines with nested parentheses. The pause is a symptom of the parsing problem where the first command following the double parentheses is read incorrectly and causes the pause.
If I modify the tool name, no error. It’s definitely the parentheses around the 1/4" in the tool name. Actually, the close parentheses is the key. Removing it will resolve the issue. Trying to think of a good solution to escape the issue:
(VECTRIC POST REVISION)
(DDE239EA63121AFD1E0950DA387FC590)
(Tool: HOG Roughing End Mill 1/4" UP CUT)
(Tool: 6.350)
(Tool Notes: #HOG - “The HOG!” 1/4" deep cut roughing bit)
That’s not really a solution. I specifically edited the post processor to add those comments for a reason. Those are valid comments in grbl gcode.
We can debate if the tool name needs to be changed to remove the parentheses but the tooldb (from IDC Woodcraft) I’m using is used by a lot of people so it could have more of an impact than just me.
It could even end up a “bug” in grbl that doesn’t allow/account for nested parentheses if gSender simply streams the gcode to grbl but forums like this are the place to understand these things
You aren’t going to get a quick resolution, so I’ve offered what I think is the solution.
Oh, another solution that you can try is to start your post-processor comments off with a “;” (semi-colon) and try adding and taking away the parentheses to see what errors out of the, otherwise working, file.
@hamanjam Since you have posted this in the gSender “bug” topic, have you tried this post processor in other code senders to see if the problem exists there? If it does, it would appear, then, that the issue is a grbl issue rather than a gSender one.
I’m not knowledgeable enough to suggest fixes, but I did search on the use of nested parentheses in grbl and found that they can be glitchy.
I just found the workaround to names and I marked this as a solution. It’s not gSender/grbl specific. There is a method to automatically change. Adding the line SUBSTITUTE will fix the extra parentheses. I added the line here and can run a test with no pause:
For example MACH 3 control software uses parentheses as comment delimiters, and does not allow nested comments. Most tools within the Vectric Tool Database have parentheses within the “Name” section; if these names are output, this would cause an error within Mach3. The command SUBSTITUTE = "({)} " would convert the () characters to {} characters, and avoid this error. For an example, see the file: Mach2_3_ATC_Arcs_inch.pp
Sorry, I didn’t mean that you and I were debating. I meant “we” as a community can debate the best way to move forward in certain situations. I found a post processor workaround to automatically replace the extra parentheses. It’s been a learning experience and I appreciate the community helping to guide
We’ve made some changed in Edge to handle this on the sender side either way - while changing your postprocessor to not do it is a fine solution, we’ve made it a bit more general to avoid this occuring in the future
