Trajectory Planner using Ruckig Lib

Maybe not so much for the simple trajectory planner but if you find you cannot simply write a single custom trajectory planner module as intended, report it as an issue on the Linuxcnc github.

This is the first attempt to write a new TP module since the modular approach was added. If it can't be done, it has to be considered a bug and the data you require should be exposed to the TP. I'm sure Dewey Garrett will take an interest in the issue.

Perhaps the simple tp also needs to be installed via the ini file to so it also has a clearly defined interface in Linuxcnc.

Hi Rod,

Maybe not so much for the simple trajectory planner but if you find you cannot simply write a single custom trajectory planner module as intended, report it as an issue on the Linuxcnc github.
This is the first attempt to write a new TP module since the modular approach was added. If it can't be done, it has to be considered a bug and the data you require should be exposed to the TP. I'm sure Dewey Garrett will take an interest in the issue.

You could write a new trajectory planner, no problem, this works excellent.

It is that code for jogging and homing are done outside this trajectory planner. And also adding INI values require
extra code to inihal, inijoint, iniaxis and so on. The lcnc command struct's and other data struct's like nml need a max_jerk value.
This is going trough the whole lcnc source code.

If you want to add a new trajectory planner properly, it's a bit like adding external offset's into the lcnc source code.

Perhaps the simple tp also needs to be ""installed"" (started?) via the ini file to so it also has a clearly defined interface in Linuxcnc.
Here indeed we need a ini argument. This is quite easy to do.

A pull request to Linuxcnc to migrate to CMAKE is going to face very heavy headwinds and could pull this project down to an exrtent it fails to be accepted.

There are 2 things. The cmake and the scurve planner. When our lcnc fork is doing things well and users step over one by one,
the dev team will eventually merge it, without me asking them. I have seen this happening before.
 

Grotius wrote:

Hi Rod,

It is that code for jogging and homing are done outside this trajectory planner. And also adding INI values require
extra code to inihal, inijoint, iniaxis and so on. The lcnc command struct's and other data struct's like nml need a max_jerk value.

Perhaps these values could be added in a seperate custom homing module that is also loaded with HOMEMOD in the ini files. It is posssoble to create new joint pins there (probably axis pins also). I have done this with joint pins. You have already said the simple planner could be integrated with an ini file.

Providing a limited jerk module would be a powerful incentive to adopt CMAKE.
My interest is in making sure you guys are aware of the existing features of Linuxcnc that support custom trajectory planners and homing modules so everything is compartmentalised in terms of the overall architecture design.

My thinking is that if the code outside of these custom modules requires changing, then the core code should be changed in a seperate PR now, rather than down the track as a single commit.
 

Hi Rod,

During the lcnc startup it prints original :
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod

We added components to jog and run programs with scurve, leaving homing untouced :
linuxcnc TPMOD=tpmod_scurve HOMEMOD=homemod EMCMOT=motmod_scurve

Above is compartimented and works excellent !

My thinking is that if the code outside of these custom modules requires changing, then the core code should be changed in a seperate PR now, rather than down the track as a single commit.

Mr Garret could look at this :  emc/motion/control.c is around 2000+ lines and at line 269 :
mot_comp_id = hal_init("motmod_scurve");

This fixed text should be made non_fixed, otherwise user can not select custom jog component.
In the cmake build, it's easy to create a control_scurve.c file. But it's code duplication. But it fix's it for now.

Sounds good. Nice and modular.
Can you provide a lin to that line. Its not jumping out for me in your repo or linuxcnc's

link to the text

Hi,

A little update.

The scurve trajectory planner works for each segment (gcode arc or line).
It start's and stops each segment, doing a scurve motion profile.
Pause and resume works, stop doesn't work for now. No blending for now.

github is updated: link to code

 

Hi,

I had to do some research to find out how the trajectory planner must behave, and how to avoid lcnc freezing during
switching auto, mdi, manual. This all is because i did'nt know or see the correct program flow.
When things are unclear, strange error's occur etc.

All of this is related how the pre-defined trajectory planner function's are used or must be used.
There is not really a explanation for it. So you are on your own.

To overcome this know-how problem i made a minimal coded trajectory template component : tp_template.c
Now this file compiles to the component : tp_template.so wich can be loaded in the ini file under the [TRAJ] section.

Now we have a working trajectory template component, that rules out wrong usage i had done before.

Most of the problems where related to tpIsDone . And how to use it.

Ok, now i can go finish the scurve component, add the stop sequence.
Test some mdi moves etc. Hopely now it will go good !

Hi Guys,

The trajectory planner is more or less working without issue's now.

Different mode's mdi, manual, auto and switching between them goes ok.
In auto mode the program does a scurve motion start & stop for each gcode line or arc.

It would be nice if a few can test the code offline & online.

Made a release for this status : github.com/grotius-cnc/linuxcnc/releases/tag/1.1

What to code next?

• adaptive feed
• look ahead
• fillets