Error on line "XX": Arc Endpoint Error - Dragknife Add-On Fusion360

I am hoping someone here can help me with these errors I am getting from Carbide Motion when trying to load the .NC file. I generated a 2D contour operation in Fusion 360, generated the .nc file (Carbide3D grbl post-processor), and then loaded that .nc file into the dragknife add-on utility in Fusion360. The resultant .nc file from the dragknife add-on produces these error codes. Any ideas what I am doing wrong?
DMT Logo Dragknife_dragknife.nc (92.5 KB)

Autodesk has trouble with math sometimes.

Switching to using metric will help to make the values smaller, but if that doesn’t work, you have two options:

  • edit the G-code and fix where their arc centerpoint calculation is wrong
  • use a different post-processor which doesn’t output arcs, or adjusts their calculation so as to keep it w/in the very generous bounds range which Grbl allows

@WillAdams Thank you. Do you have a recommended alternative post processor?

Use mm when you post process.
Try this post processor.

1 Like

I tried mm as the post processing output but it still didnt work. The link is broken to the post processor can you reshare?

Did you click on it?..it seems shared on my end.

Can you share that gcode?

Yes. It is at the top of the thread. I did click on it and it says not found.

When I click on the link, it updates to:

and shows:

Can you share that mm gcode?
Here’s the file.
grblFerreriTEST.zip (5.9 KB)

Thank you!!! Here is the mm post processed.
mm Test v1_dragknife.nc (98.5 KB)

1 Like

The first couple arcs in your mm gcode should pass grbl checks. What lines were you getting errors for with the mm version?

For anyone interested (Something wrong with you if you are), I’m checking these with a simple Google Sheet calculator I made using Grbl’s code for the Pass/Fail Calculation.

1 Like

I don’t suppose you could add a graphic module which would show how things do (or don’t) line up?

I’ve had to draw up such arcs a couple of times on Support so as to explain to folks how Grbl is not at fault.

1 Like

First, I admit there is something wrong with me :grin:. I ran into this 24 years ago, feeding Gcode into a Dynapath and dont remember the details but I ultimately had to write my own code to read the Gcode line by line and correct the error. I assumed this was due to a loss of accuracy in the software generating the GCode due to rounding in I, J. To prevent the error, I think I kept the start point, the center (I,J), and one coordinate of the end point, and recalculated the missing coordinate but this introduces its own bias from the original GCode. What is the best way to correct it?

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.