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.
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.
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 (M6)T302.
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.
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.
