I’ve been trying gSender 1.2.2 and I still have some issues. In the attached gcode file I always get an error 38 on line 140. The logic selected for handling tool changes doesn’t matter. This file has worked fine before.
test.nc (2.6 KB)
I have also had two occasions where gSender got completely lost while running the gcode file. The CNC machine would no longer run the gcode file but would just slowly move in one direction. I have not figured out how to reproduce that yet. I’ll keep trying to get some more info on it.
Using gSender 1.2.2 on a Win 11 mini PC with a low-power J4125 processor.
You may be running a gcode post processor not supported by gSender/GRBL.
If you are using Vectric software this might help How to Create a Machine Configuration Profile for the LongMill CNC in Vcarve Pro or Desktop. - YouTube
The gcode was created via Carbide3Ds CarbideCreate ver 7 and then back generated to a gcode file via CarbideMotion. That said, this is a very simple set of gCode that worked under gSender 1.2.1 (and earlier). I was using it to validate the Tool Change code for a BitSetter on a Shapeoko. 1.2.2 seems to have broke something else for me.
Check your tool number.
Grbl only goes up to 255 by default. Carbide Motion intercepts that line. gSender just passes it on as is.
Adding on to Neil’s post - previous versions (<=1.1.7) replaced the entirety of a line with a
M6 command with
(M6) which would have removed the T command causing errors which would explain the behaviour you’re seeing -
M6T302 would previously been sent as (M6), and now it’s sent as
We might look at commenting out the entire line again if it will cause frequent problems with tool numbers, but this change was part of our work on the new toolchanging strategies. Ultimately we’re trying to limit the amount of places we send something different than the actual loaded toolpath to only lines containing g-code where we need to work around GRBLs capabilities.
FWIW, this does still throw an error in 1.2.1 as well.
Thanks Ken Neil and Andy,
Yes, the issue is the last tool number in the file. I am not sure why I don’t remember that occurring in 1.2…x before but I was looking at the change in speed overrides more than anything else.
So, is there any possibility of doing something with tool numbers > 255 that Carbide3D uses to not cause errors? Maybe another check box configuration to send or not send that info on the tool change page?
We’re going to be parsing out T numbers for internal use so it’s still available to the user/UI and commenting them out again in the next release. So M6T500 would be sent as (M6T500), but the T command would still be informed to the UI/available in macros. This should fix the problem for GRBL controllers regardless of post processor used.