Hi Carl McGrath - This file.nc works fine when sent to my GRBL 1.0

Hi @Carl_McGrath - This http://file.nc works fine when sent to my GRBL 1.0 X-Carve mill. The problem is that there are many extra arcs shown in the CP 3D view, which are not part of the actual tool path.

Here’s a link to the .nc file.

Oh boy. I thought we had the G2/G3 arc stuff licked. This has been one of the hardest areas to get right in the 3D viewer. Can you try to narrow down one example line of Gcode where the arc is failing and create a Gcode file of just that arc to see how it renders to help us debug?

OH, GOOD, this time John can chase this in CP.
I fully expected to have yet another tinyG arc issue to flag.
But I kept seeing references to GRBL…
I do note that Matt’s gcode (renders OK in OPENScam) in in inches. Might inches be problematic for three.js, the way it sometime upsets tinyG?

It would not be inches since all the 3D viewer does it take numbers. It is unit agnostic. If the numbers are inches, the camera just zooms out to try to fit everything on the screen. It would be the rendering code. The weird part about arcs in the Gcode standard is sometimes there are 2 solutions to the equation and you have to pick the correct one. I bet we’re picking the wrong one.

BTW, the 3D viewer is not what’s sent to the controller. So even though the 3d view may look wrong, the job will probably run fine.

Here are some clues.

(1) This error occurs in the both the TinyG and the GRBL CP workspaces.

(2) The same error is visible in the OpenSCAM v0.2.5 simulator, but its fixed in v1.0.6 (now called CAMonics). Are you using code from that project, perhaps? … maybe you can find and diff (across versions) the code they use to pick the arc solution?

@jlauer GRBL most likely, if he were using tinyG I would probably suggest convert Gcode to mm, still seeing some outlier inch issues.

ChiliPeppr’s 3D viewer is from scratch so it uses nobody else’s code base for G2/G3 arc rendering. All workspaces uses the same 3D viewer component, which of course is the beauty of CP being a scalable solution. It’s the nitty gritty here on arc rendering and the 2 equations issue.

Problem with the GCODE generator making absolute or relative for the IJK, and CP expecting the other? Try seeing if the CAM software has an option to switch between relative and absolute ARC @Matt_Wheeler

It could be. That would be an easy fix if it is that. There may also be a choice of outputting only G1’s where the arcs get rendered by the original CAM.

+Peter van der Walt - I did try the post processor which you shared. As I mentioned, it works but it bloats my file size to near the CP limit. So that solution doesn’t really work for me.

Yes, I started a new thread because I was having trouble attaching an image. I didn’t even notice the difference between Google+ and Google Groups. I’ll pay closer attention to that. Thanks.

Which CAM are you using ?

+Peter van der Walt My nc files get too big for CP with that post processor. I will just disable the 3D view in CP.

@charlie_wallace I use Fusion 360.

which post processor in the cam are you using, and can you share a f360 file with the cam setup via a360 that you’re trying to preview in CP?

I use the GRBL post in f360.

There is a link to the generated nc file a few posts back.

Thanks for posting this, as I was just about to post/ask the same exact thing myself.

The link is to the Post I use when using Fusion 360 with a TinyG. It renders all Clockwise and Counterclockwise Interpolation G02 and G03 commands properly and machines them as well. I hope it helps you out.


Thanks @Ron_Fasbinder . Unfortunately, this Post doesn’t make my nc file render arcs properly in CP.

@Matt_Wheeler if you can, post the f360 file via an a360 link (switch on downloadable), it’d be easier to help you. the NC or the post isn’t the F360 file, those are the output GCODE and the post processing files, it is the source CAD with the CAM in it . i tried to reproduce but couldn’t. more data/info is always helpful for debugging problems