scurve trajectory planner

that is awesome!!

@Lcevette,

that is awesome!!
We hope so.

I had to add extra logic to the arc-helix.
When the arc-helix is trimmed at the front, i had to update the center point.
As the old center at the front is off plane after trimming.

The result looks ok now. Helixes in plane G18 & G19.
Deviation = 5.
 

If there are shorter segments, the clothoid fillet previews to be tinyer.

Also working on the look ahead now.

Hi all,

Tiny update.

I changed the axis gui colors to show white. This is better readable for web pages and documents.

For the code base :
The helix needed another update. When you trim a helix far enough, the helix turns "P" value is changing.
This is now also taken into account.

Had a lot off work to get the ringbuffer to work as should. It took me hours and hours.
But i am confident now.

I made about 3 example optimizers. From very simple to complexer. This to verify the planners behaviour.

Then finally the scurve has no isnan values anymore, this is fixed for ever.

So now straight on to the finish line.   LINUX FOREVER.

 

A great thank you to the team and testers! This is gonna be a big milestone for LCNC…

Well, well done!

Pierre

Hi Grotius,

this is awsome, good work.
Regarding the ringbuffer, did you already try a code with lots of tiny segments? In your example there is propably plenty of time between the g code lines to calculate the next clothoid. With lots of smaller sections we could test if it works in general.
If the calculation takes 25ms then running a g code with F6000 with sections shorter than 2.5mm might already be the limit.
Would be an interesting test what happens with a modern g code with lots of tiny moves.

Best regards,
Fabian

Hi Pierre,

Thanks for your contribution. It's alway's nice to get a few compliments so now and then.

Hi Fabian,

this is awsome, good work.
Thanks Fabian. Coding is going in the good direction.

Regarding the ringbuffer, did you already try a code with lots of tiny segments?
Yes we have a file with tiny segments : spiral_on_surface_0001.ngc
This file is the extreme example of tiny segments.

Concern 1:
When running this file, indeed there is a velocity point where the cnc can't keep up when using endvel>0.
But i have to test this when the codebase is ready to do this.
When using tiny clothoid fits, it will take less time to fit then 25ms. I will report fit times using a low G64 P[x] value.

Concern 2:
The concern is that the motion can just ignore (jumps over) tiny segments at high speeds.
The speeds are so high, one servo cycle moves more distance then the underlying segments.
Wich result in for example passing 4 segments at one servo cycle.

But also this concern has to be tested when code is ready to rock and roll.
In theory we could calculate if we are dealing with scenario's as above and propose a solution for this.

You could set conditions like : the planner should at least pass each segment for minimal 1 servo cycle.

In general, soon we can test above concern's and find a solution.

Ringbuffer info:
Regarding the ringbuffer, the lowest working size i now use is 10 segments.
The expected size to use is around 40 or 50 segments.

1. At program start the ringbuffer is allowed to add segments up to 5 at once.
2. Then with every move a new segment is added. These new added segments are in this case 5 segments in the future The clothoid fit is done when the segment is added.
3. Now the ringbuffer is rotating around 10 segments. So it was important to get it work correctly. To not
   overwrite non executed segments for example. And it must run until program is completed.
4. When the ringbuffer is working at runtime, there is no "tpIsDone" anymore during the gcode run.
   The tpIsDone clear's the buffer. And this results in delay's.
   Gladly we have ruled this behaviour out.
   It just run's without any delay's trough a program with 50K+ lines.
5. The ringbuffer is memory effiecient and needs no copy, remove, etc. in relation to a c++ std::vector

HouseKeeping:
The codebase is now using submodules.
It's worth to take a look at the readme files off the submodules.

1. main linuxcnc scurve repository: codeberg.org/skynet/linuxcnc_scurve_compact
2. submodule : codeberg.org/skynet/libclothoid3d
3. submodule : codeberg.org/skynet/libscurve

The submodules can now easely be used by other developpers to use in their projects.
Today i worked mainly to get this submodules and readme files up to date.

Note, the scurve is 8x faster then Ruckig.

For the people who want to do a financial contribution to our work,
there is a donation button at the end of the readme files.
A donation support's a non-profit organisation related to retired donkey's in the US, located above San Fransisco.

Codebase clone & runtest:

This worked ok!
 

Nice

The old tp (old old) used to hit the centre of each segment, which is what caused it to become excruciatingly slow and sorta useless for high speed contouring. So we don't want to do that.

With short segments the key is is deviation. if you set a deviation of 10 microns, then the motion simply has to slow down in certain sections to ensure its never more than 10 microns away, and yes you might blend over 20 segments to do this. The current planner is reasonably good at this in terms of keeping speed as high as possible but never deviating too far. It does create a few instances of improper deviation though that it looks like yours would fix. For example a lead into a a facing cut would blend across the long face segment causing it to not cut flat.

Since I can only look at pictures and go "oooh, ahhh", my quesiton is: how does it deal with tangential motion that exceeds acceleration abilities? You only show the helixes perpendicular to the G1 motions. So for example a rounded corner that's a G3 move, but is only 0.5mm radius. You need to basically "blend out" that G3 while adhering to the P value.

@ihavenofish,

how does it deal with tangential motion that exceeds acceleration abilities?
We calculate the max segment velocity based on curvature extrema and maxacc.
The implementation of this funtion is here.

I agree that deviation is the key. And the possibility to blend out multiple segments respecting path deviation.

Concern:
Today i experienced unwanted interpreter behaviour. I did know the problem was there, but forgot about it.

1. When no G64 Q[x] value is given, the interpreter removes tiny segments on it's own, replacing arc's with line's etc.

In the case of our planner, we have to always use the combination G64 P[x] Q[0.0] to prevent this behaviour.

This behaviour can also been seen on page 3.
The examples made by Hmnijp used no G64 Q[x] value. And planner did remove segments on it's own,
replacing arc by lines etc. Trimmed segments are clearly off path, wich is not ok.
It shows exactly the problem. If Hmnijp used a G64 Q0.0 value, the result would be very different.

Now i added this as a note to the planners readme file, that users including myself are aware of this, and don't forget about it.

With no G64 Q[x] value, we get unwanted interpreter input:
 

Using G64 Q0.0, we get what is to be expected from interpreter:

Q is a segment decimator. Setting it to 0 disables it. In the older tp it had to be set explicitly every program as the default was something useless. In the current planner the default should be 0 already. I wonder if you accidentally changed it somehow globally.

I see something in this last image which I'm sure is just a future task but it was a problem in the old planner so I'll mention it.

You should NEVER blend G0 rapid moves. And definitely not blend them into a G1.

G0 always needs to be exact stop (with jerk control). If you blend a G0 move you wind up hitting fixtures, vises, gouging your work and breaking tools.