G2 slow feed down

[ger21]

I'll have to check the version when I get home, but one of the latest test versions.

I set the both error tolerances to .25, and it made no difference. Ran the same as if it was .01.

[Robertspark]

If you put it greater than 0.5 it should not slow down

In reality the acceleration is too low, unless using 1" cutters haha....

[Robertspark]

If you have a junction between two lines I can understand mathematically how you calculate a radius at the point of intersection

Ok a junction between a line and an arc or an arc and a line I think I can probably work out.

Between two arcs... That confuses me... If the two arcs are G2, the intersecting corner error arc radius will also be G2.... Same with two G3 arcs the intersecting arc will also be G3.

If you have a G2 and a G3 the error arc will be G3....
With a G3 and a G2 arc the arc of intersection will be g2....
What I cannot figure out is how you work out the points of intersection between the " new" arc end point (start or the corner error max radius) and the new next arc start point (end of the corner error max radius)

[ger21]

1.2103
Even with both error tolerances set to 1, it still nearly stops at the transitions.

[Derek]

I seriously sat down and tried everything I could think of in the settings and I never noticed even the slightest difference in the slowdown between transitions. I firmly believe it has nothing to do with any setting we have access to. Acceleration may fix it but none of the 4 machines I have can run reliably or smoothly with super high accelerations.

I personally think something changed along the way in the planer as I remember a few years back having Terry write me a two macros. One would set all the tolerances for roughing and one that would set everything for finishing. You could see a real difference on my big router in the way it moved. So much so that if you were in one mode or the other you could visually tell. I stopped using it because somewhere along the way the difference between the two was not noticeable at all. Now I can set things to any number at all and visually the moment stays chunky. Mathematically there probably is a difference but not in the fluidity of the motion.

[Robertspark]

Obviously needs Balazs to check it out

[digger]

I am running 1.0247.

Rob, I understand what are you saying about the physics, and agree with you. But what I don't understand is why there is a hick up in speed at the places where is the transition from line to arc. I draw an new model, rectangle with two arcs at opposite sides. One arc has a tangent relation to the lines, while other doesn't. Diameter of the arc is big enough that the feed of arc is equal to the linear feed - 150. Whenever cutter goes from G1 to G2 (or from G2 to G1) there is a drop in speed. It is more visible at the places where arc is not tangent and there are more than one small arc. I understand that, there should be drop because of small arcs, but don't understand why it is happening at the places where there are no small arcs. First of all, regardless of the acceleration, because of the size of the arc diameter, and look ahead there shouldn't be and speed drop. That is how I look at this thing. CNC is my hobby, so I can allow myself to be wrong - but don't kill the messenger .

Also, I would like to know, how should I calculate / figure out what should be the value for max corner, linear err and addition and unify length. The smallest cutter I use is 1/8", so the corner and linear error should be less than 1/16"?

I increased the acceleration to 25, problem still exists, but it is less visible.

[Derek]

Obviously needs Balazs to check it out

Well he basically has. This is the same problem I posted about when I was machining the combustion chambers on my cylinder heads.

viewtopic.php?f=4&t=1066

The final post after two pages is basically that it's an issue with the planer. At least that's how I interpreted it.

Yes, we already learnt a lot from developing the UCCNC and I think I have mentioned before that we see the limits of the current trajectory planner algorithm and we already figured and thought out a different one which could work even more optimal than the current one and would have less limitations and could also implement S-curve acceleration. The current one could not implement S-curving.
So, yes, we can resolve the limitation of this example code the same time when we will implement the S-curve acceleration, because both require a new and different algorithm.

[cncdrive]

Interesting. My collegue will check it out as soon as he will be back from his summer holiday.

[cncdrive]

My collegue got back and we studied this issue and got to a conclusion that it has to work how it works now.
The reason why it has to work like this is because in the example code the X axis is moving along the straight line and there comes the arc where the the Y axis also has to start running.
But the Y axis has 0 speed at that time and it has to accelerate up. The acceleration of the Y axis will be the limit in this case and this is why there is a partly slowdown in the feedrate.
The higher the acceleration the less it deccelerates.
We have also compared this now with LinuxCNC and it works the same with this code.

Only Mach3 does not do a slowdown in the transition and it achives it with overaccelerating the Y axis which is a stupid solution because it involves the risk that the axis will loose steps.
So, that Mach3 seems to handle this transition better is only visual, in reality it handles it much worse than how the UCCNC and LinuxCNC handles it.