Dynomotion Forum

Dear Tom,
I post again to share a strange behaviour I noticed with TP.
I am currently developing a fairly fast machine and while testing some path generated by our software for Trochoidal milling (fast feed discrete arcs), I experienced a lot noise and jerky motion. I made a long test session and I report only the relevant results I found.
I use the latest 4.35f version (but since 4.35b the issue is the same).
I also disabled any smoothing via KLP to make things clearer.
I created a small test program with a simple half circle (via G3) and the a small spiral arc made with discrete segments. the segments where created by our SW according to a maximum cordal deviation from theoretical curve of 0.01mm.
When I execute the code the machine behaves differently when perfoming the arc (very smooth) and the discrete curve (very jerky).
as parameter of the TP I use: Break Angle 30.0, facet angle 0.5/1.0 (small differences), Corner tolerance 0.01mm, collinear 0.0, arcstosegs=false.
I went deeply into trajectory analysis and it seems to me perfectly tessellated: TP creates small arcs between segments consuming all the half segments (that is what i expect because we discretized with 0.01 chordal error and TP has the same tolerance for rounding): the result is a fairly rounded spiral arc. The issue is the velocity commanded along the spiral: with those parameters is strangely different from the similar arc in G3.
Even more strange if I modify CT to 0.005mm. The trajectoy still appears good (this time it consumes about 1/4 of each segment in rounding each corner) but the velocity has jumps that makes the motion a mess.
Consider Gcode has a feed of 5700mm/min and the max velocity is 200mm/s (12000mm/min) with max acceloeration of 1000mm/s2 for alla axes.
Please see velocity plots attached relative to X axis velocity with CT 0.005 and 0.01 mm; Velocity is axes "last_vel" field.
I also attach Gcode that generated the plots (M102 and M103 are acquisition start/stop programs)

Looking at the plots is quite evident the difference between the first G3 part and the subsequent discrete curve.

It is quite evident that the TP is doing perfectly well with geometry, but it seems to mess something with Feedrates of created segments.
Do I make something wrong?

Thank you

Best regards

Giancarlo

Well, I have some updates.
Analyzing the trajectory in both cases and looking how the feedrate is adjusted along the segments the behaviour makes more sense to me:

- the first case (CT 0.01) is reasonable because the requested fedd of 95 mm/s is too much for the curvature of the spiral arc. it is limited by the maximum acceleration according to the curvature formula sqrt(A*R). some minor spikes maybe due to smaller segments and some numeric errors. To bear in mind that this is a special case because CT is exactly the same of the max error used generating the spiral discrete segments: this is not always possible to match.

- the second case (CT 0.005) is more interesting: the treajectory is a sequence of straight segments and rounding curves (this because reducing CT the planner consumes less than the whole segment in rounding). At this ponit we have the straight segment at required feed (95mm/s) and the rounding curve limited by the maximum acceleration (about 48mm/s). The result, as visible from the plots is continuous acceleration and brake along path at a rate of the number of segments in the original curve. That is the reason of the terrible sound executing this path.

Is there a combination of params to avoid this effect? The first thing that comes in mind is a sort of "second pass smoothing" on the feedrates...

Another strange thing is that in the first case I should not have those vibrations at all with no sudden velocity variation along path, but if I go further with the spiral path (meaning increasing the radius) the vibration increases a lot. I can't understand why, because, in that case the curve should be always a continuous curve even at larger diameters.

I'll make a path acquisition at larger diameters to see what's going on and report back the results.

Best regards

Giancarlo

Another update.
I made further testing con the CT0.01 case because the sound was better than the other cases but something was wrong to my ears.
I acquired a larger number of samples while spiral goes on towards a diameter large enough not to be limited by acceleration.
As you can remember the first round at small radius exhibits some noise, but reasonable continuous velocity.
the result get worse increasing the radius.

Please see attached plots.
The first one shows the velocity of X and Y axes up to the radius that limits the velocity according to acceleration.
The second is a detail view with the velocity modulus added.
You can easily see the velocity jagging and the modulus as well.
Looking at the modulus we see a lower frequency oscilation, but I suppose it is due to the choice of limiting each axis with its own acceleration, thus meaning that in combined motion actual speed can overcome the single axis speed limit.

My suspect is that the generated geometry, even if as trajectory is good, has some discontinuitities in curvature. I do not exactly understand why, but seems that some segments are smaller and with different curvature than the adjacent one, so limits are applied with noticeable difference to those segments increasing locally the velocity and suddenly decreasing in the next segment bunch (where curvature is restored).

Is there a simple way to plot the exact points with associated feed velocity generated by TP?
I think it should help very much in understanding this behaviour.

Thank you very much

Best regards

Giancarlo

Hi Giancarlo,

Please see attached plots.
The first one shows the velocity of X and Y axes up to the radius that limits the velocity according to acceleration.
The second is a detail view with the velocity modulus added.
You can easily see the velocity jagging and the modulus as well.

Its not clear what you are expecting. I count 9 line segments for a 90 degree curve. So there is a line segment and a 10 degree corner repeating. The trajectory planner is accelerating during the line segments then decellerating for the corners. If you force the TP to follow that path exactly it has no freedom to smooth things.

Can you create GCode with shorter segments and smaller angles? Basically smoother?

Looking at the modulus we see a lower frequency oscilation, but I suppose it is due to the choice of limiting each axis with its own acceleration, thus meaning that in combined motion actual speed can overcome the single axis speed limit.

Correct. The combined velocity is lower where an axis is not moving.

My suspect is that the generated geometry, even if as trajectory is good, has some discontinuitities in curvature. I do not exactly understand why, but seems that some segments are smaller and with different curvature than the adjacent one, so limits are applied with noticeable difference to those segments increasing locally the velocity and suddenly decreasing in the next segment bunch (where curvature is restored).

Sorry I don't understand what you mean.


I did add a LPF Tau = 0.005 seconds and it did some smoothing and the path only seems to deviate from the original by ~ 0.01mm

Is there a simple way to plot the exact points with associated feed velocity generated by TP?
I think it should help very much in understanding this behaviour.

After a short Job runs the Coordinated motion segments created by the TP should still be in the buffer. This should print them. The format is:

Length of time of the segment in seconds
The parametric equation 3rd order polynomial coefficients a b c d
The scaling for X Coordinate and starting X coordinate where X = scale * p + start
The scaling for Y Coordinate and starting Y coordinate where Y = scale * p + start

Hi Tom,
I'm sorry but I understand that my explanation it's not so clear as I wish. MAybe I was taken by sacred fire of testing and I did not explain my thoughts in detail.
I'll try to make a better job.

Its not clear what you are expecting. I count 9 line segments for a 90 degree curve. So there is a line segment and a 10 degree corner repeating. The trajectory planner is accelerating during the line segments then decellerating for the corners. If you force the TP to follow that path exactly it has no freedom to smooth things.

You are right, but my assumption was different. As I told before, we created a sw that generates trochoidal milling path for pockets. as you can imagine it is composed of many arcs (spirals an circles mainly). In order not to have a huge gcode file, we decided to tessellate the path according to a maximum chordal deviation from theoretical path of 0.01mm. For small radiuses (as the example I reported) it results in a discrete path with about 10 deg of angular discretization that goes slowly down to 4.5 deg as the radius increases (in this particular case). As you mentioned this is not very smooth so I tried to smooth it using the TP freatures.
In particular I set BreakAngle to 30 deg (so that all the segments will be smoothed) and then I set Facet Angle to 1.0 deg and Corner Tolerance greater than 0.01. I also set collinear tolerance to 0.0 in order to have my path unchanged until smoothing.
According to documentation, doing so, should result in TP "consuming" all the segments in smoothing (because CT is greater than the original chordal deviation used to discretize the curve) and I expect a full rounded continuous smooth curve (in the attached plot you can see a perfectly smooth geometry).

With my surprise the generated path does not run as smooth as expected, generating strange vibrations in the first path stage.

Starting from this point I acquired the path with different CT values (0.02, 0.01, 0.05) in the very first stages of motion along the spiral, adding also a pure arc made by G3 because I noticed that with pure arcs the code runs very smooth.

I discovered that aside from the path that appears very smoth as expected (all the trajectory is consumed as expected), the commanded feed along this path is not smooth at all, but exhibits the strange behaviour seen in the graphs.
With CT less than 0.01 it is normal I think, because we leave some straight segments in the middle of smoothed corners so the TP start accelerating and then decelrating for the next curve, but with higher CT (0.01 o rmore) when all the path is "consumed" in smoothing, this should not happen.

But I found it is true only if the velocity is NOT limited, because if we limit it due to maximum acceleration allowed, the feedrate along the smoothed path is jagged as in the latter plots posted. Even stranger than that, if I increase CT to i.e. 0.02, I expect no change at all in path and velocity (because as we said the whole original path was already "consumed" in smoothing): well this is true for the path (looking at the curve), but not for the velocity that is more jagged than previous.

Because the velocity limits are applied as function of the path curvature, gived a fully smoothed path, the only reason I see to have a jagged feedrate is that curvature has some discontinuities, such as some straight small segments in the middle of smoothed points. Am I correct?

I did add a LPF Tau = 0.005 seconds and it did some smoothing and the path only seems to deviate from the original by ~ 0.01mm

Sure this is a possible way, but further smoothing motion will not remove the problem. The path is already smooth (see plot), the velocity will be smoothed slightly (meaning the problem is attenuated but not solved). Anyway increasing too much KLP adds error that sums up to TP smoothing... 0.01 (from TP) + 0.0125 (from KLP) means more than 0.04 on hole diameter... just from geometry (you have to add path following error); maybe acceptable in some context less in others.

I'll try to download the actual segments from the buffer to see what happens with actual commanded points.

Thanks for your support

Best regards

Giancarlo

Hi Giancarlo,

Now I understand. You are correct. Give us some time to look into it.

Hi Giancarlo,

I think we found a significant issue. When two adjacent corners are "rounded" and both use the entire segment this results in a pair of segments with double "curvature".

Here is an exaggerated test case 2 inch square with 90 degree corners rounded with 22 degree facet angles for visualization.

CT = 0.1 inches


CT = 0.2 inches


CT = 0.3 inces


CT = 0.4 inches Entire segment consumed


Ct 0.5 inches


Previous Versions would result in this where a point of double curvature would occur causing a deceleration and slowdown.


The new version leaves 1/2 of a segment facet of the original segment so when combined with the next corner results in a more consistent curvature.

Please let us know if this shows an improvement in your system


Here is a patch for Version 4.35f. Replace this GCodeInterpreter.dll in the KMotion435f\KMotion\Release folder

Hi Tom,
I'll replace the DLL and make a test asap.
I'll report all the relevant results.
Thanks.

Best regards

Giancarlo.

Well now it's a lot smoother.
No audible noise even if I run the test without KLP smoothing.
I also acquired motion data as usual and I report the results, in terms of feedrate in the plot attached (In the meanwhile I discovered how to attach pictures inline ).
As you can see the velocity plot is a lot more regular. It does not have the braking points at each arc change as before, but there is something strage as well: it seems that some of the arcs created have a sort of slight difference in curvature from the adjacent one leading to a "square wave effect" we can see on the top of curves (where they are limited by acceleration). It is not always the same pattern and way more limited in variation.
Very strange: maybe a sort of truncation error is going on? It could explain non-repeatable pattern...

Anyway I'll keep testing the whole trochoidal path to see how it runs and then I'll make some chips with it.

Thank you for the quick response and update.

Best regards

Giancarlo

Hi Giancarlo,

I think that is caused by the rounding of the GCode values to 1um. 1um seems small but on short segments it can change the relative length/angles significantly. I plotted lengths and angles of the raw GCode segments:



Can you add another digit in the GCode?