Circular cuttting with Z involvement

[cncdrive]

This would be a completely erroneous assumption on your part.

Nope, this is something which is clearly stated in the standards and all controllers which I saw so far being it a hobby software like Mach3, UCCNC, LinuxCNC, USBCNC or being it a Fanuc or other controllers, all control the path feedrate and not separate feedrates on individual axis. Please look up the g-codes standard manual to see.

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

If exact stop mode does not stop on all points in the segmented arcs with Wincnc then the implementation of exact stop mode is errorous in that software.
Please read the definition of exact stop mode in the g-code standards book.

[ger21]

In Gary's video that I 16saw, the segmented section ran exactly as if it were a G2 move. by tweaking my settings, I was able to get it to run at about 116-118 ipm. But it's not the same, as the steppers sounded like they were still moving in segments, as opposed to the smooth sounds of the G2 moves.

It's as if the lookahead in WinCNC sees that the vertices all land on the arc, so it treats it as a G2/G3 move.

Now, while in this case, that behavior is desirable, I'm not sure that it is always the correct behavior. Gary disagrees with me. Maybe it is a better way to do it. But I'm not sure if you can make the calculations fast enough? Basically, as you look ahead, if any 3 points fall along an arc, you convert it to an arc, extending the arc further as you look ahead. This would potentially greatly increase 3D carving as well in some cases. It would probably require another tolerance setting in the CV settings, and may not be possible without a re-write of the planner?

Without knowing what WinCNC is doing exactly, it's hard to say. But in this instance, the video I saw clearly showed a much better result from WinCNC. Gary needs to make another video to clearly show the difference,using the best UCCNC settings possible.

[cncdrive]

Gerry,

And how do you mathematically convert line segments to arcs?
That does not makes sense to me, because the number of possibilities is infiniate, because an arc can have it's center anywhere,
so the number of possibilites to go through to decide if a chain of line segments are on a possible arc is infinate,
so the controller could not complete such calculation in a reasonable amount of time with deciding with absolute sureness if the line chain is an arc or not.
And so you are correct with having a concern about if the controller can finish such calculation, because the answer is no, it can't, because the number of possibilites is infinate.

The other thing is that the arcs when defined as real arcs with G2/G3 they are also broken up and the controller executing them in the final step as a chain of lines,
so basicly the exact opposite is what is happening in the UCCNC, the arcs are broken up into line segments.

I can easily get the same results with G2/G3 arcs as with the segmented arcs with Gary's code and by the way that was with the default CV settings, I did not even go into tuning them to get the perfect results I showed on the video. And I tested it not only with running the software, but with a machine next to my desk and I do not hear much differences in the motors sound,
however ofcourse they may be minor differences, because the size of the line segments generated by the CAM software may be different than what size of lines the UCCNC is braking up the arc to.
Again, infinity comes into the equation, that if the CAM software breaks up the arc with high enough resolution then the differences will be smaller.
Ofcourse the arc can't be broken up to infinate number of line segments, because that would mean infinate number of g-code lines, but if it breaks it up to similar amount of lines what the UCCNC is generating internally when braking up the arc then there should be no difference in the execution of the G2/G3 arc and that chain of lines.

[Gary Campbell]

Guys...
Don't interpret my comments as anything derogatory against UCCNC. I plan on using it numerous times in the future. I am just trying to learn how to tune the software.

My thoughts are that when you say: "Nope, this is something which is clearly stated in the standards and all controllers". I might propose: What happens if the guy that wrote the other software didn't read that, or possibly didn't believe it had to be that way? There has to be something behind innovation, like not following the published rules.

Sorry, but ive seen way to many things that happen perfectly on screen or with a simulator. I like to see and hear the motors to know when the machine is happy. By the way, this has nothing to do with arcs, Ovals or a chicken shape all work the same. Don't know how, just does.

Here is a small machine doing the same type of file with an exaggerated pass depth. Jump to 38 seconds in: https://youtu.be/dKdh0uPYHJg You can hear the motors are happy.

[cncdrive]

What happens if the guy that wrote the other software didn't read that, or possibly didn't believe it had to be that way?

Gary, who wrote the standards book was not "a guy", but the NIST, the National Institute of Standards organisation.
The standard was written to advice how things on a CNC controller should be implemented.
Ofcourse controller manufacturers may or may not follow the standards, but if they don't then it will be not easy for people to use the controller,
especially for people who learnt CNC programming and who are used to the standards.

I don't see setting the feedrate by axis as innovative rather than confusing and problematic, because if you do so then the path feedrate will be something unprogrammed which is basicly dangerous in my opinion.
Let's take a simple example that you program the X and Y axis feedrate to be 100 units per minute, then if you program a just X or just Y movement then the path feedrate will be 100,
but in all other cases it will be different, it will be higher. For example at 45° it will be 100*sqrt(2) = 141.4, that is more than 40% more than what you programmed which can be a problem.
And since you programming the axial feedrates the path feedrate will be different by angle which is problematic, because you will not get a constant feedrate on movements with different angles.
And sure, a controller with this logic will finish the path faster than a controller which programs the path feedrate, if the same feedrate is programmed on both, the above example explains why,
but it will be faster only because it runs with a faster feedrate on the path as what is programmed, again the above example explains why.

Sorry, but ive seen way to many things that happen perfectly on screen or with a simulator. I like to see and hear the motors to know when the machine is happy. By the way, this has nothing to do with arcs, Ovals or a chicken shape all work the same. Don't know how, just does.

The answer is simple. It can only do that if:
1.) It has a high path tolerance and so it has a relatively large freedom to optimise for feedrate.
and/or
2.) It does not obey the set acceleration parameters.

Since the UCCNC always obeys the set parameters it will only accelerate how you allow it to accelerate it will not accelerate up faster and will not deccelerate down faster. And so the limit will be simply the law of physics, there is basicly no unknown thing in the equation, because the path tolerance is a known value set by you and the acceleration parameter is also a known value set by you.

You can say that then why don't we just let the software to overaccelerate the settings in some cases if it can run closer to the set feedrate on complex paths.
The answer is again simple, but it will require some explanation. It is because however that would cause a better feedrate maintance capability the same time if there are time points where an overacceleration happens and if the machine still have no problems with that (I mean no lost steps) then that means that that higher acceleration (used for the overacceleration time point) could be used also everywhere else.
So, this means that you can higher the acceleration parameter in the UCCNC to get an even better overal performace, faster overal execution speed than with a system which overaccelerates in some cases.

For example Mach3 has the bug in it's trajectory planner where it often over accelerates/ over deccelerates at least 2 times the value setup and this sometimes causes jerky motion, but fast execution cycles.
The UCCNC does not have this issue and if you comparing Mach3 with the UCCNC using the same acceleration parameter values then Mach3 will be faster,
but the thing is that the same time this means that you can set the acceleration parameter at least 2 times faster with the UCCNC than you can with Mach3,
because if that short overacceleration which Mach3 used caused no problem for the machine axis then the same acceleration would not cause problem anywhere on the path.
So, you set the acceleration 2 times faster with the UCCNC and it will execute the code faster than Mach3.
Probably wincnc has somekind of similar issue or the 2 acceleration parameters or the set tolerances are not the same in the comparion.

[ger21]

And how do you mathematically convert line segments to arcs?

3 points make an arc, so you look at 3 points, and if the segments are short enough, or fall within a certain tolerance, you make it a G2/G3 move. Then you look forward, and if the next point is on the same arc, you can add it.
Just thinking out loud. I don't know if it's even doable. I didn't watch your video, as I have a poor connection in the hotel I'm in.

[Gary Campbell]

I am going to swap out the CV settings later on in the week. Thanks for that. This machine is for sale and it cuts as well, if not better than most of its size. I am sorry that I poked this hornets nest as it appears nothing productive will come from further discussion on this topic.

That said, the comments:
"The answer is simple. It can only do that if:
1.) It has a high path tolerance and so it has a relatively large freedom to optimise for feedrate.
and/or
2.) It does not obey the set acceleration parameters."

Neither are true. I am not saying this. I have shown this.

Hopefully Gerry and I can get together in front of a machine one day, and he may be able to explain it better than myself.

[ger21]

The goal here is to make sure UCCNC is as good as it can be. If you don't raise questions, things don't get better.
No need to apologize for anything.

[cncdrive]

Neither are true. I am not saying this. I have shown this.

If neither is true, then:

1.) What tolerance did you allow on the path with Wincnc?
2.) Did you measure the acceleration in the Wincnc? Did you try to set the acceleration higher in the UCCNC? Or how do you decide that what I'm saying is not true?

It looks to me that you think that somekind of magic is happening, but beleive me there is no magic, the limits are always your settings which are limited by the laws of physics or there is cheating which makes you think they are not which will hit back somewhere.
A good example is the issue with Mach3's trajectory planner. One can think that magic is happening when it runs codes faster than any other softwares.
And if you don't measure it out then you never realise that it is basicly only because it is overaccelerating otherwise your machine could do 2 times higher acceleration on the whole path, so you comparing always with the same acceleration parameters using other softwares too and you think that Mach3 does magic is how it runs faster, but it is just cheating which causes you to downtune the acceleration which you will also do with other softwares without questioning the truth.
The avarage user is easily tricked to think this, because the avarage user does not know enough to even ask the question, not to answer them.
And so I think the same is happening with Wincnc, that there is cheating in the mentioned 2 points which could be only verified with a measurement of the step/dir lines with a logic analyser.

[ger21]

the limits are always your settings which are limited by the laws of physics or there is cheating which makes you think they are not which will hit back somewhere.

That was basically my thought. In order for the straight line segments to run exactly like a G2/G3 move, compromises are being made somewhere.
My first thought was that WinCNC is not following the commanded path as accurately, even though it gives the impression that it is. But it's impossible to know exactly what it's doing.