forum.cncdrive.com

I've had this problem forever. I have a ton of contouring to do and I'd like to see if I can get a handle on it.

Here is a snip of the code

Code: Select all

N1 G20
N2 G0 G17 G40 G49 G80 G90
N3 G64(CONSTANT CONTOUR OFF OR TURN ON W/G64)
N4 G54
N5 (2 1/2 Axis Profiling)
N6 T22 M6
N7 G43 H22


N10 G00 Z2.3173
N11 X2.6831 Y-1.6339
N12 G01 Z2.2187 F30.00000
N13 G17
N14 G03 Y1.3574 I0.0000 J1.4957 F80.00000
N15 G01 X2.2863
N16 G03 Y-1.6339 I0.0000 J-1.4956
N17 G01 X2.6831
N18 G00 Z2.3173
N19 G00
N20 Y-1.6222
N21 G01 Z2.2139 F30.00000
N22 G03 Y1.3457 I0.0000 J1.4840 F80.00000
N23 G01 X2.2863
N24 G03 Y-1.6222 I0.0000 J-1.4839
N25 G01 X2.6831
N26 G00 Z2.3173

Here is a video of what I am experiencing. Smooth as silk in the arcs and a pause at each line segment.

https://youtu.be/udWrQQ-lAiY

I'm attaching .pro . I'd like to know what I have to loosen up in order to get smooth motion. Here are my current settings.

Probably Linear Addition and Linear Unify.
Try them both at 0.1.

As Gerry said, linear unify and linear addition lengths are very low.
The addition length means that the software is not allowed to add longer line or arc segment than that to the lookahead process.
The unify length means that the total length of the unified segments can't be longer than that.
In both cases when the segment or the sum of segments is longer then the software is forced to deccelerate on the next endpoint, because this is what these parameters mean.

You can set these 2 parameters much higher in most cases, they can be even several inches long.
The issue a high value can cause is if you for example have a lower angle connection on the path than the set stop angle,
let's say (just a simple example) you have a square 90°connection and you set the stop at angle to 91° and e.g. that line is an outer contour, a side on the workspace which you want to be square,
then if the mentioned 2 parameters are longer than the side and the connection angle is lower then the stop at angle then the side will no more be square to the other sides,
because the software will look ahead into it and will optimise the path in a way that it will run off the path with upto the max. linear error parameter,
which in your case is likely still not a problem, because your linear error parameter is really low and the unparallelness will be only with the value of the linear error value, so the difference, the unparallelness will be small value.
However if the linear error would be also high and the above mentioned values would be used then the issue could become visible on the example toolpath.
Ofcourse setting the angle to 89°would also fix the issue at a 90˛connection even if the linear error would remain high.
I hope you guys understand what I'm trying to explain.

I kind of get it. I'll bump up the values like Gerry suggested and post my results.

Thanks for the help.

Derek

Ok no luck.

Changed them both to 0.100 as per Gerry's suggestion and saw no difference. Bumped them all the way up to 3.0 and saw no difference. Increased all the other fields and it made no difference.

I put the machine into exact stop and I can barely see a difference between exact stop and constant velocity so I did a test. I ran a longer version of the code I posted. With CV on and according to the UCCNC timer it took 53 seconds. Putting it in exact stop it took 52 seconds. so it's a second faster in exact stop? It's almost like it is ignoring constant velocity.

I always assumed that my settings were off but now I'm really at a loss.

Are the arcs tangent to the lines?

Try loosening up the corner error.

Acceleration can have a lot to do with it as well.

This maybe a long shot... run the statistics graph and check the communication loop latency timing. What version of UCCNC are you using?

I ran your code and it runs fine when the acceleration of X and Y are the same or close to eachother. It runs without decceleration then even with your so low tolerance settings.
In your settings they are 7 and 15 for the X and Y, so they differ a lot and then the deccelerations happen.
So, it seems that this difference is causing the deccelerations at the connection points, but I have sent the file and settings to my collegue for analysation, so after that I can tell you more, if it is normal for the CV algorithm with these settings or if it is abnormal and if it is somekind of error.
Meanwhile you could try to adjust the acceleration and test.

I changed the acceleration on X to match Y and it was better but I'm still getting a pause at the end of each segment.

The geometry is a circle cut in half, pushed apart and joined with 2 lines so this isn't exactly challenging. Or at least it shouldn't be:)

Hopefully your colleague will have some input.

Thanks
Derek

With same accelerations on XY what I see is a drop from 80 to about 76-78 units/min feedrate.
My collegue studied the issue and he said that it is caused by how the trajectory planner works and that it is not a bug and that he cannot fix this.
To fix this exact case the whole trajectory planner should be rewritten using fully different algorithms which we can't do now.