Arc Junctions, corner error max? linear error max? ??

[Robertspark]

Ok, here is another / different one

Think of it as an " m " with two arcs

the code is as follows (2 x 500 units radius arcs, with G02 moves. The first semicircle is broken into two quadrants.
Acceleration is 5 units/s/s, feedrate is 10160 units / min
Corner error max = 10 units. All other error tolerances are ZERO.

Code: Select all

G02 X500.0000 Y500.0000 I500.0000 J-0.0000 F10160.0
X1000.0000 Y0.0000 I0.0000 J-500.0000
X2000.0000 Y0.0000 I500.0000 J0.0000
M30


https://youtu.be/7WdrRdEcH14

As you can see the motion deviates from the first semicircle at the junction of the two quadrants by ~ 20 units (gets as high as 480+ a bit) and motion slows down.
When motion comes down to the point of the "m" with the intersecting arcs it stops....... this is where I would have thought that the corner error max parameter would have been applied.
The next arc is a semi circle and as you can see it follows the arc closely and the feedrate gets limited to the centriperal acceleration allowable for an arc of 500 units and acceleration of 5 units/s/s

_____________________________________________________________________________________________

Ok then next is my attempt at what I think "should" actually happen.... (I cheated.... drew it in Autocad (day job for me).... before you wonder how I go the co-ordinates then used sheetcam )
It is the same sort of thing " m " but this time it consists of two large (almost semi-circles) with the junction of the two semicircles having an inlaid 20mm diameter (10mm radius) "Corner Error Max" G03 motion between the two G02 moves

Code: Select all

G02 X990.1961 Y98.5282 I500.0000 J0.0000 F10160.0
G03 X1009.8039 Y98.5282 I9.8039 J1.9706
G02 X2000.0000 Y0.0000 I490.1961 J-98.5282
M30


https://youtu.be/_uXdUVjFxZo

Ok the deceleration velocity should only go from 3000 units / min down to ~424 units / min .... it drops a little lower this is because the actual "corner error max" setting was left at 10 units..... if I made it zero, the feedrate would have dropped from 3000 to zero to 424 to zero to 3000 and it would have become exact stop motion.

[cncdrive]

Rob,

I'm sorry but I will not post mathematical expressions publicly, because I do not want to give ideas to the concurency.
Also please forgive me, I don't want to offend you or anybody with this, but this thread will be a waste of time only, first because what I wrote above, second we will not change anything on the current planner and this circles optimisation limitation was already brought up several times by several people and so we will not go into it again, it would just waste some days of our time again when we could work on constructive things instead of checking again and then again expaining the details.
We will build a new planner anyways with less limitations and the current one still works better than several other controller's, so you guys will have to live with this until we will make the new S-curve planner.
Again, I have no hard feelings at all and don't want to offend anybody at all, I'm just trying to be honest with you guys. And I know sometimes my honesty looks like as if I was upset or something, but I'm not at all. You know I'm an engineer and so I work with logic and not with feelings.

[Robertspark]

Do you think the s-curve planner will solve this issue?

This issue does not seem to be acceleration based.

What does cause me a problem is that I was trying to look at a plasma macro to improve bolt holes using something like a phi (golden ratio) spiral to allow for improved smooth motion relative to required federate , with using M10/M11 with overburn (similar to true hole) this throws a bit of a spanner in the works because if I break the circle into quadrants the planner will slow down at the quadrants / arc junctions when I am trying to get it to accelerate, then maintain federate, and then decelerate.... Not fluctuate.

If the same junction algorithms are used with the s-curve planner .... The acceleration fluctuation will still be there and the junction deviation appears to be up to twice the corner error max setting between two arcs that have the same origin.

I understand that you are busy on other things. What I don't understand is why you now come back and say it's not a problem and are going to do nothing about it but it will somehow be solved by a new tradjectory planner.

Sorry it is a problem and an unnecessary one.

You have a planner that offers constant velocity ..... But it cannot actually do constant velocity..... Unless you apply a large corner error and accept that all arc junctions will be inaccurate.

Set corner error max to zero and it becomes exact stop.
Set corner error to your expected allowable error and the planner doubles the error on arcs of the same origin.

In too am an engineer.

I don't deal in feelings but fact and the fact is you have a problem that you fail to acknowledge or declare to users to they could be able to qualify and account for it.

[cncdrive]

The new planner will work on 100% different algorithmical and code base. I hope this explanation is good enough for now, because I'm really tired of too much work recently and don't have the energy to ask collegues to verify code, discuss, explain, convince, argue, discuss, explain, convince etc. It was done already a few times about this same issue report.
Please understand that we will not make any changes to the current planner, no matter if it is a real problem or not, because as I wrote earlier the planner will be replaced.
So it does not worth to waste time checking. I'm sure you understand this, because you wrote you're an engineer.
And since over 20000 machines already using the current planner and something like 5 people reported this as a real problem I think the solution can wait until we finish the new planner. The numbers say that it is not an as urgent issue that we will have to work on it immediately like how we usually do when issues are reported.

[ger21]

My interpretation of what he wrote is that I believe that they are aware that there are issues, and they plan on fixing them with the new planner.
If these issues aren't addressed, then the new planner would be a waste of time.

This "issue" is really the only thing keeping UCCNC from being one of the best controls out there. Even though it's already really good.

[cncdrive]

Hi Gerry,

Yea, I know. The "only issue". When people try to convince us to do something asap then they always saying this.
Like how it was the only real issue with the missing G41/G42, so we added it.
And issue with not enough tools (was 20 only) we added more (98).
And issue with no detailed tooltable, we added it.
Then the issue with missing G93, we currently adding it.
And issue with lots of other things which people reported over the time as missing things or things they want in other words. We added all as far as I remember.

So, my question is why do you guys think that we will not address this limitation of the planner in a new one? Please give us a bit more trust.
The thing is that it is just waste of time in the current stage of development, because we will not change the current planner anymore, because it will be replaced, so is why I think it is a waste of time to discuss this further now. And I don't want to waste your time guys and also don't want to wait my collegues time too, because then the new planner will also be finished later.

[ger21]

Yea, I know. The "only issue". When people try to convince us to do something asap then they always saying this.

That's because you've given us everything we've asked for (Except for maybe Terry's requests )

If I didn't trust you, I wouldn't be here. Keep up the good work.

[Robertspark]

My interpretation of what he wrote is that I believe that they are aware that there are issues, and they plan on fixing them with the new planner.
If these issues aren't addressed, then the new planner would be a waste of time.

thats great,

Rob,
... but this thread will be a waste of time only, ...

its not a waste of time unless you don't acknowledge it {which you have done} understand the extent of it {I've covered 2 scenarios, not the third yet}, and have solutions for it {that I'm sure you will consider, and have considered with regards to current implementation ease or future integration when the s-curve planner is commenced}

first because what I wrote above, second we will not change anything on the current planner and this circles optimisation limitation was already brought up several times by several people and so we will not go into it again, it would just waste some days of our time again when we could work on constructive things instead of checking again and then again expaining the details.
We will build a new planner anyways with less limitations and the current one still works better than several other controller's, so you guys will have to live with this until we will make the new S-curve planner.

fine, you've considered the last bit and considered its too difficult / a waste of time to integrate now, yes I am aware of all of the other threads on the same issues:
viewtopic.php?f=3&t=1541
http://forum.cncdrive.com/viewtopic.php ... +error+max


I never expected for it to be fixed "now!" ... I already acknowledged that...

Yup I know you are busy on the next development release and those sales are what keeps us all here so they are your priority.
Its no rush on this one as uccnc works its just one of those "hmmm.... why does it do that?" moments + I'm sure the next development release will keep everyone busy for a while

but quantifying the problem, like I said

its just one of those "hmmm.... why does it do that?" moments

allowed / allows me to look at the issue (which I never really did in any great detail) and to try to understand how the planner works with what settings, and what settings affect what and the scale of it

If you look at the youtube clips you'll see that they don't have any titles or explanation at to what they are showing. Anyone looking at them will get very bored very quickly looking at a dot following a line so they will not damage your sales / uccncs credibility by listing a minor issue if that is what you are worried about.

I am not trying to convince you to do something asap.

Simply by looking at a problem and trying to quantify it and explore options to correct for it {change corner error max, allow for double corner error max, allow for slowdown on arc junctions}, + allow for it is "not trying to convince you to do something asap". It is just exploring the problem in more detail than "there is a slowdown with arcs".

I have been thinking about the idea of making the plasma cutters amperage setting adjustable on the fly (this is possible on the newer + larger hypertherm "XP" models via modbus) but I was thinking about the possibility of doing is much more dynamically and using a faster protocol than rs485 ascii via a digital pot, I have been thinking this over for some time regarding selecting the "right digital pot", making it isolated, using the right protocol in a high noise environment etc etc.

Investigating the issue is not just to resolve the issue, but it is to have understanding of the issue to allow for compensating for it.

And that is all I've been trying to do.

It is only a

... but this thread will be a waste of time only, ...

if I {or anyone else} don't learn anything from it

I would have thought that whoever develops your trajectory planner would have a read this thread and others like it to maybe review the issues and to try to deal with them in their development

I am sure that the new planner won't have this issue, but it will probably have others. That is the nature of development. Problems are never really solved they just pop up with new problems that are brought on by the solutions to the last "issue"

CLASSIC EXAMPLE.....
viewtopic.php?f=3&t=1530&p=11627&hilit=sheetcam#p11627

Advice was to split the circles into quadrants.... so that the circles won't be skipped.... great..... but now they slow down at the junctions of the quadrants.
At least the circles cut..... but understanding the slowdown and settings involved allows to mask the one issue by trying something else.

[cncdrive]

Rob,

I've talked to my collegue now about this issue report, because I see that you guys don't want to let me off the hook.
He said that with the current planner it is impossible to implement what and how you want it to work, it is a limitation of the planner. It can only work how it works now.

The circle skipping on syncronisation is a totally different issue, it is a mathematical/g-code wise logic problem, it is not a UCCNC specific problem. Any other CNC controllers can skip full circles the same way in those same situations, like how mach3 doing the same and it is not because of a bug in both softwares... but we have discussed this already on the forum...

And I'm not worrying about loosing sales or money, it is even good if we loose some now as we are too much overloaded and overstressed at the moment with the end of year sales madness.
What I'm trying to do is that I'm trying to describe that no matter if it is a real problem or not, I mean if we consider it as a problem or not, we will not fix it now and so I think it is logical that if we will not fix it now then why check it out in details now when we already know about this limitation as it was discussed more than one time already. This is why I'm saying it can be only a waste of time.

And the only way to correct this limitation with the current planner is if you
1.) Will not use arcs.
OR
2.) Will use high enough acceleration when this will become unnoticable. It is similar to how Mach3 randomly makes incredibly large path errors and overstepping the setup accelerations with low accelerations setting which you can fix only with tuning the acceleration higher.
The same is with this arc issue, if you set the acceleration high enough then it will become unnoticable, because the slowdown is not a full stop, but a jerk in the acceleration whose amplitude goes lower as the acceleration settings are higher.

[Robertspark]

2.) Will use high enough acceleration when this will become unnoticable. It is similar to how Mach3 randomly makes incredibly large path errors and overstepping the setup accelerations with low accelerations setting which you can fix only with tuning the acceleration higher.
The same is with this arc issue, if you set the acceleration high enough then it will become unnoticable, because the slowdown is not a full stop, but a jerk in the acceleration whose amplitude goes lower as the acceleration settings are higher.

...funny enough I noticed that.....