Regarding tool changes, either output a separate g-code file for each tool or switch to a g-code sender that handles M6 tool change instructions in a sensible way. I wrote my own that basically just pauses the program, allows you to do a manual tool change (including jogging), then resumes the program without sending the M6 line out to grbl.
Regarding error 33, I have run millions of lines of CamBam-generated code through grbl and have never seen this error, but apparently it can be caused by excessive rounding, i.e. not enough precision in the numbers sent in the g-code commands:
https://softsolder.com/2020/03/18/grbl-error-33-arc-coordinates-vs-decimal-places/Basically the code is telling grbl to move through an arc that is physically impossible. This might either be a problem with the postprocessor you're using (I use a slightly altered version of the included GRBL post), or your g-code sender might be rounding-off the numbers before it sends them.
The postprocessor I'm using has the "Number Format" parameter set to "0.0###" which causes it to output 4 digits of precision. My g-code sender doesn't do any rounding.
I don't believe it's true that grbl was originally written to control laser cutters. It was originally meant to control basic 3 axis routers/mills and the laser-specific features were added much later. It does lack some advanced features such as macros but there's no reason you can't use it with CamBam to drive a router.
