SolidWorks grbl Post processor

I have not had any luck generating usable G-code for my Genmitsu 4040-PRO using SolidWorks 2023 CAM. I have tried both posts “SW_GRBL_POST” and “GRBL-Post-main”. Candle squawks on the output G-code. Any ideas?

I no longer have an active SW licence, so I can’t check what options it has.

Can you share the actual text of the “squawk”?

Have you tried using UGS as a sender?

Hi Michael,

Here is the G-Code using the SW_GRBL_POST. Candle errors on lines 2, 8, and 10.

N1 G90 G54 G00 Z-3.3505 M08
*N2 (2.9mm JOBBER DRILL)
N3 S10672 M03
N4 G54
N5 M08
N6 X23.655 Y-13.246
N7 Z25.
N8 G83 G98 R3. Z-3.3505 Q2. F433.722
N9 X56.345
N10 G80 Z25. M09
N11 G91 G28 Z0
N12 G28 X0 Y0

I don’t know what UGS is??

This code works… I wrote it manually.
Drills two holes…

M3 S6000
G0 F100
G1 F100
G0 X100.000 Y100.000
G0 Z-15.000
G0 Z0.000
G0 X150.000 Y100.000
G0 Z-15.000
G0 Z0.000
G0 X0.000 Y0.000

UGS= Universal Gcode Sender

OK, I don’t know which comment modes Candle supports, but grbl definitely doesn’t support canned cycles like G83 drill cycles or G80 kill canned cycles, so SW including it assumes that a rich sender that interpolates macros is in use.

Sadly, it appears that UGS does not support interpolating canned cycles:

FreeCAD also has the weird choice to send G83 in its grbl post by default (though there it’s at least an option now), apparently because the one person working on it happens to use bCNC and that does macro interpolation.

You might check whether the SW posts have options not to use canned cycles, and you might try using bCNC as a gcode sender.

Thanks Michael for all of your help. I don’t think this is the right controller/software for what I am trying to do. Keith

It hadn’t occurred to me that a sender would interpolate canned cycles for controllers that don’t handle them. I guess it’s a neat feature but I imagine it could be mysterious when debugging fine motion problems.

Anyway, TIL!

1 Like

Yeah, before cheap 32-bit controllers, when memory was precious, offloading everything possible made sense.

I think they must have thought about bCNC + grbl as kind of like klipper today, with both together as the single system for running gcode. At least, that’s the impression I get from reading some old forum posts.

Hi Michael,

Any suggestions on a good controller for a benchtop mill that can handle standard G-code?



Well, grbl handles standard gcode, just not all of it that you want. :relaxed: There are lots of different flavors, and even pro equipment differs from controller to controller. So “standard G-code” might not be enough specification to give you an answer that satisfies you.

In all seriousness, personally I’d strongly consider starting by just using bCNC as a sender. They really do think of your computer as part of the controller. The gcode interpretation is being done on both sides of the connection, a cooperation between the PC and the controller board running grbl.

I have typically used FreeCAD for CAM and told its grbl post not to use canned cycles, or used Kiri:Moto which doesn’t expect them, depending on what I’m cutting.

The new generation of grbl, grblHAL, supports some canned cycles including G83. I don’t know whether its canned cycle support is sufficiently extensive for your interests. Here is the supported hardware list for grblHAL

Smoothieware supports drilling cycles if you enable that configuration though I haven’t tried it.

But maybe you want more than just drilling cycles, and it turns out that smoothieware doesn’t support it?

If you want a really rich gcode environment, LinuxCNC on a raspberry pi driving any board that can run Remora is probably a good choice? It’s what I’m personally planning to put on my CNC mill as my next step.

Splitting the difference: If you get a board that can run Smoothieware (noting that the original, official Smoothieboard is in short supply due to pandemic part shortages), then if it turns out Smoothieware doesn’t know the gcode you want to use, you can get a raspberry pi (well, hopefully, given shortages of that too!) and put the two together to use LinuxCNC + Remora.

Looking at other open source firmware, it looks like reprapfirmware allows you to drop in custom macro files for canned cycles, and klipper is probably the same, but neither supports G83 out of the box.

Hi, I have exactly the same problem as you with exactly my same machine as you, have you been able to find a solution or on other processus ? Sorry for my English, I’m French! THANKS !

Have you tried using bCNC as your sender?

I am in the same boat, searching everywhere and trying to find a post processor that will allow me to do everything through Solid Works, The closest GRBL post processor that I found works, but plunges -4 in the Z to start and then in the program its retracing up to far, I figured out how to make it work on a trial, but I don’t want to manually correct every time.

If only GRBL were open so post processor vendors could support it.

Most likely it’s the complexity of GCode that’s throwing them off or because there’s no money from GRBL to pay to do the post processor it languishes in a proprietary software package. Just a thought but does SolidWorks output a good STEP model which FreeCAD can import and post process to GCode?


I have found one which is working (at least it seems so, because not a lot tested yet).
It’s here (bottom of the page mill and lathe versions)


I could probably do that, I just wanted to give it a try through solid works first. Almost ready yo give up and go that route. Any suggestion of what to use once I have it in a step file?

Thanks I will give this a try tonight.