LinuxCNC S-Curve Accelerations

Hi Spumco,

From user perspective it's a logic explanation from you.

If you look into the previous linked c file, you can see functions like : tp_addline or tp_addcircle or tp_isdone.

In the original tp.c file there is a queue vector that has a size of about 10 lines of gcode.
I speak in therms of gcode to keep it simple. It's actually line, arc data, some speed and acc data etc.
It comes close to a actual gcode line.

Every time tp_done=1, the queue may be updated with new gcode line. It works like a c++ vector operation.
It can add a line, remove a old line from the bucket. The queue is like a tiny program that feeds the component.

For me it's not clear if i don't use the queue bucket to hold the gcode lines, why it's dumping the whole gcode file at once
if i do a tp_isdone request.

The first request goes ok, second request is dump mode.

And it's not clear to me where the tp_addline, tp_addarc requests actually came from?

With the bird eye view, i can search for the functions, but these 2 appear only once.


The goal is to clean up the original tp.c file to something minimal that is working, even without vel,acc etc.
It just has to do a working cycle. May even be without moving the tp itself.
From there i have a nice and clean starting point to integrate the scurve code.




 

Just to highlight that the correct way to build a custom tp is to use a component based on this skeleton
github.com/LinuxCNC/linuxcnc/blob/master...mponents/tpcomp.comp
Docs:  linuxcnc.org/docs/2.9/html/man/man9/tpcomp.9.html
I don't see the code yet following this template.

This is also how custom homing modules are created.

Spumco, I don't think this code touches the gcode parsing code but it is also modular too.

There is so much flexibility built into the linuxcnc framework, yet nobody has really attempted to make custom modules

Hi Rod,

I don't see the code yet following this template.
It's exaclty following this template. This was the easy part.

I followed the template. Using the tpcomp.comp as starting point was going ok.
Mr garret's comments where perfect starting point. In no time the app was running.
It took me less then one hour.

But then the comments falls back to replacing the original tp.c file to your custom_tp.c file.
Then you are on your own...

The tp.c file is around 3000 lines. Quite a difficult point to start?

The idea was and is to minimalize the tp.c file. So that there is a clear understanding of the program flow.
At the moment i have some insights. But at some points i am missing something.





 

For the one's who are interested, parts of the scurve lib is already brought to c component style.

It already run's in a component. Exciting, the first part is almost finished.

I had to dive into writing c again.

scurve_c

Hi,

The question is no longer a question.

I added a parameter of type bit for testing.

When this param is set to "true"
it pops a gcode line of the queue.

So for now i will try to keep the queue code intact.
There is still a lot to figur out.

This is good news.

in tcq.c there is a funny text :

Ok then.

   

The idea is to expand the parameter list with relevant tp.c stuff.
Then we can get a nice impression what is going on.

I get more and more the idea i could directly test some scurve's
without modifiying a lot of code.