GRBL Error 25, 35 and many more

Hey all!
I seem to have some issues with GRBL Mega. It frequently put out error 25, wich I was able to solve with reducing speed aswell as micro stepping. But that only helped error 25, now GRBL gives me error 35. But the code seems fine.
I initially ran shallow cuts at 1800mm/min with 1/16 micro stepping (4X80st/mm+800st/mm(Z)), wich gave me Error 25 aswell as Error 1,2,24 and 35.
After setting the machine up with lower micro stepping and way less speed (with more doc to compensate the lost time) I get mainly error 35. If I let the program run via $C no errors are shown (Except the last line, e.g. code has 3000 lines, error for line 3001).
The errors are coming up randomly, grbl seems to have trouble with a line, next try it doesn’t.
What I tried so far:

2 Arduinos (JoyIt/Keyestudio)
Checking and refreshing the 16u2
2 Laptops with Mac Big Sur (from 2014) and a new Linux one
Diffrent cables
Running the program with no ramps attached with the original 20cm cable in an e-magnetic clean environment (Not $C mode as that always seems to be fine)
CNCjs and UGS (UGS with different sender options)
Reducing the tolerance in Fusion to 0.001 and keeping the GRBL at 0.002.
Updating the F360 Postprocessor for GRBL
Tried out the GRBL PP for Carbide 3D, X-Carve and another one I found somewhere (more errors)
Reducing speed (delayed the show up of Error 25)
Reducing the micro stepping (delayed the show up of errors)

Even though it shouldn’t have any effect on the problem, here is my hardware wich is pretty standart:
Arduino Mega(clone)
Ramps 1.4 (modified to not fry the arduino at 24V)
5x TMC 2208 V2 and V3
5x NO Endstops
4x 1.5A Steppers 1,8°
1x 1.7A Stepper 0.9°
2 parallel relays for Makita spindle
120W 24V trafo (I know it’s undersized, it just came with the machine)

I’ll post my GRBL settings aswell as config.h and the NC codes. (changed format for upload, usually .h or .nc)
config.gcode (46.6 KB)
x deep&slow.gcode (785.2 KB)
x fast&shallow.gcode (3.2 MB)

Please ask for more details if needed!
Any help is highly appreciated!
Thanks a lot!

1 Like

I wish I could help. Maybe one of the more experienced grbl users will pop in. @ttraband maybe?

Downloaded GRBL Mega yesterday once more and flashed the arduino with it. Now everything works at full speed with max Microstepping. It’s weird, because I tried this once before without changing anything but nr of axis and homing routine and limits. And the two other times I tried it I changed some more things. To me it seems like either I have typos in all three previous tries or the the data got corrupted somehow by getting it out of .zip
Now everything works like a charm, except my settings for the gcode wich led the z straight into the workplace instead of an angle :smiley:
Anyway, thanks for the support, case closed. Love this forum <3


I was just starting to look into this and was going to say it sounds like commands (or parts of commands) may be getting lost between the PC and the controller. I’m glad you’ve got the issue resolved.

For anyone interested, I found this list of grbl error codes on the official grbl wiki. I saw similar lists on other sites but they don’t specify which version of grbl they’re from, so I thought I’d post a pointer to what I hope is a reliable source.


By now I can give you the text to the error codes in the sleep :smiley:
Out of interest, is it really possible that the files got changed/sabotaged by unzipping it or loading it to the arduino or was it human error the whole time? I know there are issues here and there, but on a repetitive task (downloading the same files 4 times, unzipping them, changing the bare minimum twice and a bit more the other two times and flashing the arduino) this shouldn’t happen.
Am I right to blame me or is it not that unlikely to have 50%(minimum changes) or 75% fails in such a process?

Unzip should be deterministic. So is compiling and uploading. I would consider it less than 1/100 chance of any of those steps doing anything different. And most of those errors would be caught before you got the binary to the microcontroller.

To be clear, I didn’t mean to imply that commands weren’t being done properly during the setup process. I meant to say there may be some interference preventing the gcode commands being transmitted by the gcode sender from getting received and properly interpreted by the controller (due to bits getting lost or echoed in transit somehow). My suggestion would have been to try a USB cable with a ferrite choke to see if that made a difference.