forum.cncdrive.com

Hi,
I'm moving to UCCNC from Mach3 (while also making a bunch of other changes in my tool chain) and I'm having trouble with a piece of GCode.

I'm running UCCNC 1.2031 (for the 2017 screenset) as well as 1.2029 with the default screen, and a UC400ETH connected to a G540.

I'm getting hung up on this:
G0 X27. Y11.8625
G43 Z0.6 H1
Z0.2
G1 Z-0.125 F23.3
G3 X26.9375 Y11.8 R0.0625 F70.
X27. Y11.7375 R0.0625
X27.0625 Y11.8 R0.0625
X27. Y11.8625 R0.0625
G1 Y11.815 Z-0.1202
G0 Z0.2

UCCNC is giving me an "invalid arc" popup message and stopping the program run. The file has a bunch of these arcs defined by G3 Xnnnn Ynnnn Rnnnn, and I am seeing a ton of similar error messages in the pane under "Run from here" when I load the file.

As best I can tell, it's valid GCode which runs well in a software simulator. I've successfully run programs with arcs of the IJK variety just fine on this machine under UCCNC. Is "R" format not OK? Any thoughts?

Thanks,
Rich

I have tested your code with UCCNC version 1.2029, but I do not see the problem, the arc draws and executes without errors.
Please see the attached printscreen.
Are you sure this code causes the arc error? Maybe it was a different one than what you copied here?

The UCCNC generates an arc error if the arc radius is smaller than the half of the 2 endpoints distance, if so then the arc can't be fitted on the endpoints with the programmed radius, so it is then an invalid arc.

Thanks! I'll dig in a little more and check. That was the one closest to the line number where it started throwing an error, and it was the first arc after the movement lines it was able to complete, so I'd assumed it was the one.

Is it going to stop when an invalid arc tries to actually execute on the machine? When it hits the look-ahead window? I've been using Mach3 with a parallel port for a few years, so the newness of both UCCNC and the external motion controller are affecting my debugging intuition.

Fwiw, Mach3 will allow arcs that are technically invalid and would not run under most other controls.
Where did the code come from?

I generated it with Fusion 360. I've been using Vectric, but I'm a Mac guy, and I'm trying to move my CAM processes to Fusion so I don't have to keep using Parallels, as it's a pain.

I used the Mach3 post with Fusion 360 to get my GCode. I reran the same toolpaths with both WinCNC and RS274 posts. That turned out more familiar IJK rather than R-formatted arcs, so it at least made a little more sense to me. I'm going to give them a go on the machine tonight to see if it makes any difference.

I also found a discussion on a StepCraft forum that hinted it might have been a Fusion setting issue with the Tolerance value when building the toolpath. I have adjusted versions for that as well. The code looked the same, but since I'm not sure which is the troublesome arc, it's tough to pin down whether the change was meaningful.

Well, it looks like it has something to do with the Fusion 360 Mach3 post. I tried a few tweaked versions of it, and they all produced the same error. I used exactly the same toolpath with both the WinCNC and the RS274 posts, and both of them ran fine. The WinCNC seemed like it was maybe a little smoother on the Z plunges, but that may have just been me searching for a difference.

The only difference I see in the actual files between the two is that RS274 always includes an Nnnn at the beginning of the line and WinCNC doesn't. the actual movement commands looked exactly the same (and were IJK arcs rather than R arcs). I'll have to do more testing over time to see if one is preferable. At least I know to stay away from the Mach3.

Thanks,
Rich

Yes, I've heard from a few people earlier that the Fusion 360 post has this problem with the arcs tolerance,
but as far as I remember the issue was fixed in their UCCNC post processor with they adjusted the arc radius tolerance lower.

The UCCNC justs protects you from inaccuracies is why it does not run not valid arcs, because if that mentioned condition meets that the arc radius is smaller than the half of the distance between the 2 endpoints then you mathematically can't fit an arc on those points.
You could fit an elliptic arc, but not one with constant radius.
The UCCNC API could still execute an elliptic arc like that, but we think it is better if the software just does not allow invalid arcs to execute.