Circular cuttting with Z involvement

[Gary Campbell]

I do a lot of machining of circles and curves with Z involvement. Most of the time I post these using Vectric software, which will output a complete circle as G2/3 moves with 4 90* arcs making up a complete circle when no Z change is required. A spiral interpolation with Z depth change will be output as line segments in the .005 to .020 range depending on the diameter. A typical 3" diameter circle will have 4 to 5 hundred lines.

I am not able to get either one of these conditions to run satisfactorily in either exact stop or CV mode. In no case was the programmed 120 ipm feedrate ever achieved. In ExStop mode the segments caused a jackhammer effect at each node and then started and stopped at each quarter circle. In CV mode the file ran somewhat smoother but displayed 2 distinctly different feeds and neither was near the set 120ipm set feedrate.

I am of the belief that when given a G2/3 command, the controller will generate a set of segments or points that closely represent the diameter/radius of the arc to a temp file, execute them and then return to the next line in the file. Assuming this is true, why is the controller able to run that code when it is self generated, but not when it sees the same code presented in a cut file? And why do circular motions require a feedrate reduction? What is it that I may be doing wrong?

[cncdrive]

Yes, the controller breaks down the whole path to small line segments including arcs, so there is no difference in executing arcs than executing lines.

Ofcourse in exact stop mode the lots of small line segments can cause a jackhammer effect, because exact stop mode means that the controller has to stop at every points, the exact stop mode is defined as that,
so the many line segments will likely cause a low feedrate and a constantly changing feedrate, because the controller has to accelerate up and deccelerate down to stop on every endpoints and if the line segment is short enough then with the set acceleration parameter it may be unable to even reach the target feedrate, because the path is too short to accelerate up to the target speed and to deccelerate down to zero speed.

In constant velocity mode the arc from many line segments are optimised out for fastest possible speed execution using the CV parameters, so in most cases it will give a faster overal execution and a more constant feedrate. (depends on CV settings and acceleration).

In all cases the controller has to obey the law of physics though and has to use the acceleration parameters and the CV parameters you setup.
For example the smaller the arc the less the controller may be able to keep the feedrate, because a circle has a constantly changing movement vector, so the machine axes are continously changing the axial speed, and the controller has to obey your acceleration setting, it can't, it is not allowed by you to accelerate faster than that, so it may not be able to reach the target feedrate because of this constraint.

However your mentioned D3 helical arc with F120 is large enough to not cause any significant slowdowns even with low acceleration.
I verified the same and attaching a video of an arc like that. I used only 50 units/sec/sec acceleration settings for the axes and the default CV parameters.

[ger21]

Gary sent me some sample code, and a video showing WinCNC running the same code, and WinCNC ran the segmented ramp exactly the same as if it were G2/G3 moves. I could not get UCCNC to do the segmented ramping as fast as it did the G2/G3 moves. I had planned on posting some sample code here to get your advice on CV settings, but I'm traveling for the next 4 days, and can't get to it until later next week. Maybe Gary can post his code, and share his sample video?

[cncdrive]

OK, please post some codes when you will have a chance.

[Gary Campbell]

Thanks for looking at this. Gerry gave me some CV setting, which I can get to you, but not til later.

File is 3" dia circle. With the "spiral" option checked, Vectric will output a segmented circular G1 set of moves (~430 points approx. .020" long) with '.125 of negative Z. Then will output four "quarter circles" at full depth (-.125) as G2/3 cleanup of the ramp down.

the math: 3" diameter, 9.42" circumference. at 120 ipm should take ~4.71 seconds plus allowance for accel/decel. UCCNC executes the (2 revolutions) file in 15 seconds (~80 ipm average) and WinCNC does it in 10, which is close to desired feedrate.

There is also a substantial feedrate change between the "segmented" section and the G2/3 pass. Note: G2/3 pass is executed at ~5 seconds

Sample code is attached. file extension changed from .tap for compliance

Truncated video uploaded here: https://youtu.be/4ZFoBad0uAQ

[cncdrive]

OK, I have checked your code.

First, the feedrate is set to 100 ipm and not to 120ipm, I see the thing that:

F120 XY [SET FEEDRATE FOR X AND Y]
F100 Z [SET FEEDRATE FOR Z]

That probably the feedrate wanted to be set 120 for the XY and 100 for the Z, but this is not how it works in the g-codes standards, if it works like that in Wincnc then it is it's weirdness, because it does not works like that.
The feedrate is set on the path as defined in the RS274NGC standards book and not on individual axis.
What these 2 lines mean for the UCCNC and probably for any other machines except maybe wincnc is to set the feedrate to 120 and after set the feedrate to 100, so finally the feedrate is not 120, but 100.
So, comparing the execution times probably failed on these 2 lines.

Second I ran your code with the attached CV settings and it finished in 12 seconds and it maintanined the feedrate close to 100ipm pretty well as you can see it on the attached video.
I also tested it on an actual CNC desktop machine next to me and the feedrates are pretty much the same for both the G2/G3 arc and the segmented arc,
the feedrate value on the screen only fluctates a bit, because of the calculation method of the feedrate, the updates rate is fast to make a responsive screen, so it can't be very precise, so with segments the value calculation for showing the value on the screen is not as precise as with a real arc, but the values are still pretty close to the programmed 100 as you can see.

[cncdrive]

And the promised CV settings attached here.

[cncdrive]

And if I set the F to 120ipm as you wanted to then the UCCNC also finishes in 10sec as on the attached video.

[cncdrive]

And the screen lagging on the videos is only the Screen capture software, it ofcourse does not happen like that in real.

[Gary Campbell]

Thank you for the CV settings, it will be a few days before I can test with them as this little machine is off to the side to make room while I complete a few orders.

"First, the feedrate is set to 100 ipm and not to 120ipm, I see the thing that:

F120 XY [SET FEEDRATE FOR X AND Y]
F100 Z [SET FEEDRATE FOR Z]

That probably the feedrate wanted to be set 120 for the XY and 100 for the Z, but this is not how it works in the g-codes standards, if it works like that in Wincnc then it is it's weirdness, because it does not works like that.
The feedrate is set on the path as defined in the RS274NGC standards book and not on individual axis.
What these 2 lines mean for the UCCNC and probably for any other machines except maybe wincnc is to set the feedrate to 120 and after set the feedrate to 100, so finally the feedrate is not 120, but 100"

This would be a completely erroneous assumption on your part. The feedrate for velocity group XY IS set at 120ipm and is set for Z at 100. That was an example posted for my WinCNC machines. That controller uses a totally different velocity management system that includes a setting, based on centrifugal force of curved vectors, allowing higher speeds to be maintained on either segmented or G2/3 moves. It is based more on an CV AND ExStop rather than OR.

I am not sure of the total number but I have seen a dozen or more controllers operate the spiral interpolation of arcs. Of those, only Mach 3 and UCCNC have produced the slowdowns and the jerky motion when in ExStop mode