Circular cuttting with Z involvement

[cncdrive]

Yes, it could be only known what is exactly happening if we know the settings, at least the acceleration and the programmed velocity and then making a measurement on for example an arc with capturing the step/dir signals. Then it would be relatively easy to see if there is any over-acceleration or decceleration and the executed path could be drawn from the step/dir signals along with the original path from the g-code file, so it could be seen what is exactly happening, what the path following accuracy was.
We did the same thing with Mach3, measured the signals out and then is when we realised that it does not obey the settings and that it overaccelerates/deccelerates and this is the trick why it finishes paths faster than any other softwares when using the same settings, but at the same time the measurement also made it clear to us that we can basicly set the acceleration parameter at least 2 times in the UCCNC which does not have this defect or cheat, compared to what it is set in Mach3 and it will still run smoother and without lost steps and then the UCCNC runs faster, because in arcs or in any paths which has lots of changing vectors directions the most influential parameter for execution speed is the acceleration. It is easy to cheat with the acceleration and most users will don't know about it, they will just downtune the acceleration, because they will think they loose steps because the acceleration is too high, which is true, it is too high, but not because they set too high, but because the software is over-accelerating what you setup.

[Gary Campbell]

You are getting totally sidetracked. First, I do not think there is any magic going on, you think that I do.

I am not. you just don't understand what I'm saying.

I feel that the point that I am trying to make is that if a controller, any controller, can execute a series of self generated coordinates, aka G2/3 arcs, why cannot it run the same code at the same speed and velocity when it is presented in a cut file? That is the real question. Answer: Some can.

It can, look at my videos linked to this forum thread, it runs your G2/G3 arc code and your segmented code with the same speed.
The higher you set the tolerance and the acceleration there will be a point where the physics will allow to run as fast as you want, except in some cases, e.g. sharp full direction changes and where the parameters you setup will not allow to run that fast.

As to velocity: The cuts made on my machine (mill)did not exceed the set XY feedrate of 120 ipm, it just came very close maintaining them. It simply was able to execute the segmented code as it would have executed a gcode circle. Just as the small machine did when executing the G2/3 code. It would have held that speed until I reduced the Z feedrate below 13ipm. Then it would have slowed down as to not exceed the set Z feedrate. By the way, I can cut a spiral down oval the same way, at the same speeds. 120 ipm is a reasonable feedrate for that size geometry, and .125" is a reasonable, if not conservative pass depth.

When did I talk about exceeding the feedrate? Answer: Never.
Feedrate is velocity and accelerating is the first derivative of velocity, they are totally different things.
I was always talking about over-acceleration and not about over-velocity.
Velocity does not have to be higher than the set value for over acceleration.
An acceleration may be value X or value 2X or 3X etc., the only difference you will see is a faster path execution since the target feedrate will be reached faster and especially on arcs where the direction of the movement vector is a constantly changing variable the acceleration is what is one heavy ruling factor about how fast the path can be executed, because if the acceleration is low and if the radius is small enough compared to that then a high feedrate can't be maintained, because of the acceleration limit, except if the controller does not obeys the acceleration parameter and using a higher acceleration.
This is all elementary school physics (7th or 8th class here in Hungary if I recall) though, this is a fact and not an opinion, the basic rule of physics. If you say this is not true then basicly you saying that physics does not work how it works on earth is why I told you that I feel like you think a magic is happening, because overruling the physics is what is called magic.
And I'm still just saying as I did earlier that for the UCCNC the limit is the settings and the settings you make are limited by the rule of physics (because for example an axis can't do an infinate acceleration) and if the feedrate can't be maintained on a path it is because your settings do not allow the software to do so, in other words it will be phísically impossible with those settings and that it is only possible if the settings are not taken into account which was the thing I called "cheating" in my previous posts.

[ger21]

Gary, I think you really need to show them a comparison video between UCCNC, and WinCNC, so that they can understand what you are telling them. Without the video, they can't really know what you are describing.

I feel that the point that I am trying to make is that if a controller, any controller, can execute a series of self generated coordinates, aka G2/3 arcs, why cannot it run the same code at the same speed and velocity when it is presented in a cut file? That is the real question. Answer: Some can.

Imo here, feeding the control a series of G1 moves that make up an arc is a very different thing than the controller converting the G2/G3 into a series of very small straight segments.

In order to cut the way that WinCNC is doing, I would think that it has to be making some assumptions regarding accuracy? Because it has to be going outside the commanded path.

I've attached some sample code that might demonstrate the issue. According to Gary, and from what I've seen in his video, WINCNC will run the two circles in this code EXACTLY the same. UCCNC will cut the ramp in of the first circle some amount slower, and it should be clear that it's following the segments, rather than cutting the smooth arc that Gary is looking for. I'm in a hotel right now, and can't test it, but even in demo mode I can see the feedrate fluttering during the segmented ramp in.

[cncdrive]

I ran the code and the feedrate is still 125 on both paths, except that on the segmented one the value fluctates a bit, like between 122 and 125 if I see it clearly, this might be only because of the fast feedrate calculations since the segments are still not a real arc, just a close approximation to an arc and as I wrote previously feedrate calculations to be shown on the screen are made with a fast rate, based on very small portions of time, so the shown value will be not as precise as with a real arc.
I could not test the code on a machine thought as I'm out of the office and also not at home at the moment...
The total execution time is the other thing I could still verify now without a machine and it is around 8sec for both code parts.

[ger21]

I'm not at a machine either, but that codes seems to run a bit faster than Gary's for me as well.

The notable difference will be the sound of the motors. In Gary's WinCNC example, the motors would sound exactly the same for both. In UCCNC, it was noticeably different.

This code might be a better test, with smaller circles.