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!