New Trajectory Planner - Testers/programs wanted

Simulator here only so far. Both run here, too. On the simulator here, the polyline speed is more consistant. The spline slows down to transistion to the next spline segment. I'm afraid the speed change will show up on the piece. Not a problem to convert to polylines, just wondering if I can change something with the spline version to be more consistant.

PK

Yes - for whatever reason the trasitions are not tangent arc-line or arc-arc. Because they are not - the trajectory planner falls back (slows down) to the original parabolic blending for those segments.

Paul wrote: My spiral was made in Inkscape which was saved with thier version of an AutoCad R14 format. That's where the splines come from. I then converted the spiral to polyines.

Thanks...

PK

Skunkworks was faster; I was just going to give the same answer.

This seems to be one of those typical 'welcome to CAM-software' issues. If the new TP is good enough in optimizing line-line transitions, there is virtually no problem anymore since everything can be approximated using line segments. Nice solution? No. Practical? Yes.

exactly.. And in the future there may be a solution for other segment transitions..

sam

DaBit wrote: Skunkworks was faster; I was just going to give the same answer.

This seems to be one of those typical 'welcome to CAM-software' issues. If the new TP is good enough in optimizing line-line transitions, there is virtually no problem anymore since everything can be approximated using line segments. Nice solution? No. Practical? Yes.

Thanks!! I appreciate the extra set of eyes. I'm not dumping on this new trajectory planner. I don't know much and just wanting experts opinions. I am seeing arc-arc (via splines) with nothing in between. Thank you.

Paul

skunkworks wrote: exactly.. And in the future there may be a solution for other segment transitions..

That would be nice, but if it was my priority list it would not be on top of it.

Handwritten code already runs really OK on the current TP. The new TP solves the line-line and line-tangent arc transitions that are so important to make CAM-generated code run well. That covers most code, I suppose.

Here is what I am seeing on a sim with slow acceleration using G64 P.001 Q.001

There is a lead in move, a straight move, a circle made up of 4 arcs then a straight move and a lead out move.
It then repeats with a lead in move, a straight move, a complete circle, then a straight move and a lead out move.

The current TP runs the first portion slow as it is prepared to stop at each section of the arcs, then blends on to the straight exit section.
The second portion it runs the circle faster then blends on the exit.

The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

To recap - so far the readahead works with
line-line segments
tangent line-arc segmetns
tangent arc-arc segments

Which makes sense if tangent arc-line is not complete yet. But again the first section of line-arc and arc-arc is a great improvement on achieving a smooth cut.

Rick G

Rick G wrote: The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

I ran your test file, and I think slowdown you're seeing was fixed in the experimental branch. I'm working on an update to push out to the beta branch that will fix this and a few other minor issues.

Rick G wrote: Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

I'm seeing this too, and I think it's because Naive CAM is turned on (Q0.001), which combines the lead-out move into a single segment. Since this new single segment is the last move in the program, there is still that pesky exact stop. I'm looking into ways to get around this limitation, but it's surprisingly tricky. There isn't currently a way for the motion module to know that a program is complete. Falling back to a parabolic blend on-the-fly is tricky because parabolic blends have a lower max acceleration. One thing that could work for this is reducing the acceleration that the optimizer sees for the last segment, so that we can safely fall back to parabolic blends on the fly. If that works, I should have a fix out today.

I am also looking into line-arc and arc-arc blends. The good news is, I've managed to get line-arc blends working in some circumstances (see attached). Unfortunately, I'm still working some bugs out, and the line-arc code is rather messier than line-line. The trade-off with circular arc blends is that line-line stuff is mathematically easy, but anything more complicated has to be handled case-by-case. Luckily, as you said, line-line intersections are the most common.

-Rob

wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )

thanks for all your hard work!

sam

rellenberg wrote:

Rick G wrote: The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

I ran your test file, and I think slowdown you're seeing was fixed in the experimental branch. I'm working on an update to push out to the beta branch that will fix this and a few other minor issues.

Rick G wrote: Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

I'm seeing this too, and I think it's because Naive CAM is turned on (Q0.001), which combines the lead-out move into a single segment. Since this new single segment is the last move in the program, there is still that pesky exact stop. I'm looking into ways to get around this limitation, but it's surprisingly tricky. There isn't currently a way for the motion module to know that a program is complete. Falling back to a parabolic blend on-the-fly is tricky because parabolic blends have a lower max acceleration. One thing that could work for this is reducing the acceleration that the optimizer sees for the last segment, so that we can safely fall back to parabolic blends on the fly. If that works, I should have a fix out today.

I am also looking into line-arc and arc-arc blends. The good news is, I've managed to get line-arc blends working in some circumstances (see attached). Unfortunately, I'm still working some bugs out, and the line-arc code is rather messier than line-line. The trade-off with circular arc blends is that line-line stuff is mathematically easy, but anything more complicated has to be handled case-by-case. Luckily, as you said, line-line intersections are the most common.

-Rob

skunkworks wrote: wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )

Glad to hear it! It's been a little quiet lately because I've got a few features in development, but they aren't quite ready for testing. I'm trying to get at least one out today, and also push the stable fixes to the beta branch.