Xcarve + tinyg randomly cuts circles and triangles then returns to the gcode

I’ve cut a few jobs on my xcarve + tinyG and run into this issue with two of them.
My work flow is:

Inkscape save to plain outline svg
open in makercam.com, create tool paths save g-code
open in chilipeppr

The g-code loads perfectly no erroneous tool paths, but when i begin the job i don’t know when the machine
may want to add a triangle or circle in the processes. The job will run to completion, adding the extra cuts on
every pass until the pocketing is complete, unless i stop it out of irritation.

Google Photos

Google Photos

I have had limited success by scaling the images in makercam either larger or smaller, but sometimes it may eliminate
the erroneous carving in one place only to have it show up in another place.

My guess this is this problem comes from an incompatibility in g-code commands. Can anyone suggest a planner that
will output gcode the tinyG can handle every time?

any suggestions?

Do you see the triangles and circles in chillipepr when you load up the file? they should come up on the preview if it’s already in the g code.

They do not show up in the preview, either in chilipeppr, or in makercam, i can zoom in and look at all the paths and nothing looks out of place.

It is pretty frustrating because It doesn’t show up in the preview. my best guess is that the gcode that makercam.com exports isn’t fully supported by the tinyG, so when it tries to cut an arc to be more efficient it cuts a circle instead. I have no idea about the triangles…that just blows my mind.


I wasn’t expecting THAT! Ok, I can’t really help with your issue but you asked for suggestions for a planner and I just checked and Fusion 360 has a tinyg post processor. Not sure if that would help or if you’re in the mood for learning 360!

I’ll have to look into it, I guess my other option is just get a different motion cotroler. It is a crazy thing. Too bad there isn’t a check box on makercam to select for tinyg.


Could you share your svg, makercam settings and the g-code produced from makercam? I can see if I can reproduce the errors you are seeing.

You could also upload your svg into easel, create your toolpaths and then export the gcode to run with chilipeppr. I do this quite often and had excellent results.

redbud.practic.nc (1.1 MB)

Settings are as follows:

Tool .0625
stepover 40
safety .5
stepdown .0312
feed 30
plunge 15

in playing around i also found that sometimes if i have a problem area I can eliminate it by selecting that area and making it a separate pocketing operation in makercam. Not sure why that would make a difference.


Can you post your g-code?
Maybe we can see something in it.
My first thoughts are, if it is in the g-code than it has something to do with the post processer settings for makercam. Probably something with Arc and Circles settings.

I recently switched to a tinyg and have been using my modified grbl post processor in VCarve Pro with any issue (yet).

If it is not in the g code…?

Its looking more like a might need to either purchase software(vcarve) or a different controller, maybe the 3-axis dsp inventables sells and go to linuxcnc. Either way the cost is almost the same to get back in the game.

Based on what I have seen in this thread it probably has something to do with the post-processor is not entirely compatible with the tiny-g.

I just took a look at makercam.com and I don’t see any post processor options. My recommendation is to try a different CAM software.

At the very least try your SVG files with Easel. It can’t send to the TinyG but you can export the G Code and load that into chilipeppr. See if you are still having issues.
(And as I mentioned I have not had any problems using a grbl post processor with my tinyG so far.)

Other people have been having good results with fusion 360 (free but big learning curve)
I use VCarve Pro - which I really like, but it is $$$ and also has a learning curve.
MeshCam looks pretty good. Not many frills but reasonably priced.

I think it’s worth checking that you’re using the very latest grbl version. Anything before 0.9i doesn’t support the G40 command you’re using. And as stated here:

“Please note that unsupported G-code may cause Grbl to behave oddly, for example drifting into a corner.”

Looking at the G code it is full of G2 and G3 commands (Circular interpolation)… I never see these in my code, everything is G1 (linear) my guess is this it the issue.
So yeah a different CAM package is needed.

Ill have to look up a list of supported commands on the tinyg. I knew alot of the big boy commands were not supported with the gshield/grbl + arduino, so i opted for the tinyg assuming(blindly) it would take in more commands, but not knowing which ones is my fault. I came from hand coding loops and variables that ran on a lovely morbidelli cnc with 12 tools…so this has made me back up and punt to get the same kind of output.

Nothing stands out as unusual in the G-code… What version of JSON server (current: v1.92 [as of 04/2016]) and TinyG firmware (current: v440.20[as of 04/2016]) are you using?

After some thought, I do recall having issues with makercam when there were overlapping features. It was finicky when selecting multiple features and/or overlaps, and I was doing simple designs with rectangles and circles…

I would recommend giving Easel a try and see if the result can be reproduced. I have had great success using Easel to generate g-code which I then send to my TinyG with Chilipeppr (see my blog post).