Arc + Ramp = Helix issues

[msimpson99]

I just started using UCCNC on one of my machines and am having an issue with ramps and arcs at the same time. I have a simple circle test that I ramp into. The code is using Arcs(G3) and it does not arch where it ramps. You can even see the error in the display.

If I do not use arcs, it ramps fine. If I do not use ramps, it arcs fine.

I have a writeup with lots of pics here:

UCCNC issues

Would appreciate some input.

Similar Threads:

• contour ramp not doing a helix around arcs
• Ramp?
• Ramp/Ramp out Contour help
• How can I ramp off....
• Mpheid post. Helix ramp

[dezsoe]

Could you please post your test g-code and the imported UCCNC profile?

- Mach3 makes some things strange, so the fact that something works in Mach3 doesn't mean that these things are good.
- Some of the default settings are different in Mach3 and UCCNC.
- Some of the settings cannot be imported from the Mach3 xml.

[dezsoe]

Also, tell me your UCCNC version, please.

Quote from your linked article:

It does not look like the UCCNC is calculating this correctly.

I think, it's a little strong. Do you really think, that hundreds of users never recognised this issue?

[Dan911]

Hi Msinpson99,

The importing of Mach3 XML is a nice feature but like Dezsoe already pointed out it's not Mach3 and it some cases settings may need to be tweaked within UCCNC to accommodate the imported settings.

Another really nice feature with UCCNC among many is there support forum.

forum.cncdrive.com ? Index page

[msimpson99]

I have no idea what other users are using. If its something simpler than that, that would make me very happy as I just want to give my CNC builders more options.

Im running 1.2037 of the software. I added the two files. I added the .txt extension to the profile so it would upload.

[dezsoe]

Thank you for the files! I will check it tomorrow (today: it's over midnight here in Hungary).

[ger21]

I'm seeing the same thing in 1.2043.
Very strange, as the code looks correct, but very poorly written. Is that from Fusion. For some reason, the arcs on the left side are displaying as straight segments, but when I do a simulated run, it seems to actually follow the arc?

Certainly looks like it may be a bug??

I've run several similar files, arcs with ramps and helix's, and have never seen this before.

[msimpson99]

Its from Vcarve Pro. I have tried several post processors (even ones that were supposedly for UCCNC) and they all do the same thing. OK I have a little more understanding as to what is going on. In the cases where the tool is ramping down Vcarve does not do arcs but small transitions so the failure is on the G1 portions of the code. In any case they should not be interpreted as straight lines. If you look at the display it looks that way.

[islaww]

Gerry...
When Michael says: "Its from Vcarve Pro." I'm thinking that you might have actually seen this before

[ger21]

OK I have a little more understanding as to what is going on. In the cases where the tool is ramping down Vcarve does not do arcs but small transitions so the failure is on the G1 portions of the code.

No, actually, it's not. If you look at the toolpath in an isometric view, and step through the g-code, you'll see it step through the G1 moves just fine. After the G1 ramp moves, there are 9 G3 moves that make up the circle, and the problem is with the first 4 or 5 of them. Stepping through the code, these lines are not highlighted like the others, and they are the one that are not drawn as arcs.
How did you draw the circle? Normally, V Carve would output a circle as 4 equal arcs, but you are getting 9, and they are all different sizes. Almost like it's not an actual circle, or it was edited in some way.

Gary, this is something completely different to what you are thinking, I believe.

[msimpson99]

I have been working with Balazs, and its actually two things going on here. The display, which shows the little straight lines where the plunge ramps are taking place. That is a known display artifact. My problem is that the cut was echoing the exact same thing and was gouging. He had me change both the Linear Error Max and Corner Error Max to .001. This helped but the cut is still a little rough where it does the plunge ramp. And to me not acceptable. I'm still unclear what is going on.

[msimpson99]

When Vcarve does arcs and ramped plunge cuts it breaks them down differently. The plunges are not arcs. It is the same if you do tabs. The actual tabs are actually a lot of little G1 XYZ movements, then once the target depth is met it does a G3 arc. If you are doing 3D tabs you end up with a ton of tiny little segments. Some of them with only .0001 or less transitions.

I did the same gcode with SheetCam and it does it all in about 20 lines of code.

The bottom line, I dont care about the display, its the cut that matters to me. I don't care how we get there as long as things are consistent from job to job. When things don't go as expected, my builders will come to me not CNCDrive. I just want have all my ducks in a row if I put my stamp on the UCCNC software.

[ger21]

I was mistaken about the 9 arcs.
I just created a similar circle in Aspire, and got similar results.
The ramp length has something to do with the number of arcs, and where they are split up. My arcs are in different places than yours, and while the problematic arcs in your file are all consecutive, the ones in my file seem to alternate, Very strange. I attached the file.

It sure looks like a bug to me. If you combine the problem arcs with the one that follows, by editing the code, the problem seems to go away.

I made another circle with a larger diameter, and it was better, but still seemed to have one problematic arc on each pass. The problematic arcs were very short.

[ger21]

The display, which shows the little straight lines where the plunge ramps are taking place. That is a known display artifact.

Did you send Balasz the file?

Again, the ramps are displaying properly, it's the arcs after the ramps that are displaying wrong.

I haven't run it on a machine, but the CV settings should not need to be adjusted to run this code properly, imo.

[msimpson99]

He has the file and my KReduCNC profile as well. If the default CV settings need to be changed because I am using inches, then these need to be posted somewhere. I remember back when I started using mach3 (in the good old days), I has issues, but after posing on this forum I had all the settings I needed. Its like in the military when you are told something you don't have to understand it, you just have to accept it. And guess what, to this day I'm still using those CV settings and have cut thousands of parts with all kinds of CNC machines.

I want to do the same with UCCNC. If I cant, I need to know now so I can move on. Someone out there is using inches and has the CV setting dialed in. That's what I want to start with.

[ger21]

Imo, this is a bug, and not a CV issue at all.

I edited your file to remove all of the G1 moves, and it still has the same display issue.


UCCNC is not Mach3. Mach3 doesn't have any of the CV settings that UCCNC has. Which is why UCCNC is far superior to Mach3. This is a bug, and will get fixed.

If you don't want to learn how to properly setup the software, that's up to you. The default CV settings are in mm's. If you are using inches, divide all the values by 25.4 to get comparable settings. But realize that the appropriate settings for each machine may be very different, depending on how fast you are cutting, and the acceleration settings you are using.

[msimpson99]

Just knowing all the settings are in mm, helps me make sense out of things. And by doing the calculation will give me a good starting point. I can then fine tune each of my machines and pass the config file on to my readers.

[ger21]

I posted this on the UCCNC forum, and the display issue was confirmed as a bug.
I was also mistaken about the actual cutting issue, which is apparently completely unrelated to the display issue.

There's a huge difference with how Mach3 and UCCNC handle CV modes. While Mach3 has a few CV settings, none of them provide precise control over path deviation. Mach3 typically performs best with all of their CV settings turned off. This usually results in very smooth, blended motion. On a circular cut, this actually gives very good results. But on other things, like precise 3D carvings, it can be very inaccurate.

UCCNC, on the other hand let's you precisely define the allowable path deviation, and provides 4 settings for this. How they function can be a little hard to wrap your head around. Because you are specifying the exact deviation, in cases like this, you may see it not running as smoothly as Mach3, depending on your CV settings. The reason for this, is that UCCNC is actually following the g-code more precisely than Mach3.

[msimpson99]

I divided the following CV settings by 25 and problem solved.
Thank Gerry

Linear error max = .001
Linear addition length max = .04
Linear unify length max = .08
Corner error max = .001

I will now use these settings as my defaults for all my inch based machines.

I'm positive if I had set my machine up in mm, I would not have wasted half a day tracking this down. I really feel the software should have set the defaults for me when it imported the Mach3 config file. That said, I will at the very least post the above information on my web site.

The display bug is still and issue, This bug is kind of what side tracked me, in the first place, but has noting to do with my actual cuts. As the it still exists. I can live with that for now.

The following is the test cut made with machines. It came out perfect. As did the Mach3 cut I might add.


It is dimensionally within .003 which is very good for this material. The edges are all smooth and free of any lines or stray cuts.

The machine I am testing on is the KReduCNC build that I originally did for Servo Magazine. Its a very small desktop machine As CNC machines go, this project was more about the education of the build, but will do repeatable accurate cuts if you stay within its limits.

Its on the opposite end of the spectrum from my KRMx02 machines, so I am curious as to the default settings listed above when I get around to testing the UCCNC software on them.
The KReduCNC build is also listed step-by-step on my website for anyone curious.
KReduCNC Introduction — Kronos Robotics

[A_Camera]

I divided the following CV settings by 25 and problem solved.
Thank Gerry

Linear error max = .001
Linear addition length max = .04
Linear unify length max = .08
Corner error max = .001

I will now use these settings as my defaults for all my inch based machines.

I'm positive if I had set my machine up in mm, I would not have wasted half a day tracking this down. I really feel the software should have set the defaults for me when it imported the Mach3 config file.

Thank you for getting back on this and informing us about the simple solution. You made me worry a bit... but I was convinced that if this was a real bug CNC Drive will fix it EXTREMELY fast.

The manual could perhaps be clearer, but it mentions that "The parameter is defined in Units" several times...