Error 33

Also post the Fusion file.

And, you are using our Post right? : docs:software:fusion360 [OpenBuilds Documentation]

 

in the post options, turn on 'linearize small arcs' and regenerate your Gcode.

 

Sure. Use a toolpath containment strategy.

Google "fusion 360 toolpath containment". Lots of videos and posts on the subject.

 

Always keep Arc Tolerance and other advanced Grbl settings at their defaults - non-default values lead to weird behaviour that you'll have a hard time troubleshooting later

Post your Vectric file for a better check on what may be happening

 

If we dissect that line of Gcode we can get an idea of what is going on.
G3 X24.0944 Y9.8490 I-0.005 J-0.0497
G3 indicates a CCW arc.
X and Y are the endpoint, the start point is 'where we are now' which was on the previous line of code
I is the X offset from the previous point to the center of the arc
J is the Y offset from the previous point to the center of the arc

We can see from the small values of I and J that this is a very small arc radius.
The problem with small offset values is that the difference between the start radius and the end radius can quickly get out of hand, GRBL detects this and gives the error 33 if the difference is too great. (GRBL wiki has details if you want to know more)

The total solution, which I implemented in the Fusion360 post, is to detect small arcs and force them to be linear moves instead of arc moves. What is a small arc? The Fusion code compares the current bit radius to the arc radius and decides on that basis :

Code:

if (arcRadius < toolRadius) then linearize.

Why that particular comparison? Because I tested(1), over a number of hours, all the scenarios I could think of and this is what worked consistently across many tool sizes and in particular SMALL tools. This is because Fusion uses tool radius for setting lead-in and lead-out arc sizes so the smaller the tool the smaller the lead-in/out, and small arcs are the ones that cause problems. Simply using a small fixed limit sometimes failed because Fusion does some weird stuff in the background that is not documented anywhere I could find.

Assuming that Vcarve does the same sort of thing when generating paths then this same solution can be added to that post.

(1) testing involves a process like 'change the post code, generate Gcode, load Gcode in CONTROL, run the code through GRBL in check mode (any problems, run again in full mode), repeat'.

As Peter said, changing the GRBL arc settings will not greatly affect this problem, and is thus not a solution.

 

As our posts make use of Vectric's core Grbl posts as base-posts, you may need to approach them directly for tech support on this one - you are welcome to include this thread's link so they can see the recommendation as well

We use

Code:

POST_BASE = "Grbl_mm.pp"

and

Code:

POST_BASE = "Grbl_inch.pp"

(Vectric support will know what that means, basically, our post doesn't format the GCODE for Grbl, the base-post does, we simply change header and footers etc a little from what the base post does)
Sidenote, do try the Millimeter post if you are processing in Inches - the base10 math may round off better?

 

SIM just moves through the positions. You want to see if Grbl (the firmware on the controller) has trouble calculating the radius - by either running the job as an aircut, or by running it through Grbl's Check Mode: Grbl v1.1 Commands · gnea/grbl Wiki