Trajectory Planner using Ruckig Lib

@Arciera,

Thanks for the links !

As @rene-dev mentioned to me it is currently not possible to run tests in parallel, mainly because there can only be one linuxcnc instance running at a time.
It seems not so easy for me to create hal instances in a short time period. Segment fault.... Huh.
Then i looked more in detail to the rtapi code.

I came to the conclusion that linux cnc hal at runtime is clamped to a single cpu core.
If user installs a preempt rt kernel, we can use posix.

This posix is then is used by rtapi to run's a pthread very fast and quite time stable.

So what looks like a insmod command in rtapi, is not a insmod command at all. Insmod in this case is not a kernel insertion command.
Insmod in rtapi is loading a .so lib.

Rtapi can be seen as a library function loader. And does a little more.

For run(); read rtapi_app_main();

So if you have a lib called test.so. This lib has a function run();
Then the Rtapi opens the "test.so" lib and finds the function "run".
The lib stay's open and rtapi creates a pointer to the function run();.
This pointer is used later on to execute the run(); function.

The rtapi then finally has a list of loaded .so libs  with their names and their run(); functions (or pointers * to the run(); functions).
This final function list is then executed in order.
All the .so libs, have the same function name to execute.

This is basicly what rtapi does.

The hal environement is coded in c. But can eventually be coded in c++. Because rtapi is also written in c++. And there is no
real .ko hocus pocus.

Transforming hal into a multi instance hal environment is quite a lot of work i have seen so far. It also comes with some
difficulties to solve.

In the end of this post :
Will take some time to create a rtapi look alike example.

Creating a test app that load's .so libs with a certain function. Then run the function list.

But then with examples how to choose the cpu's.
How to set priority flags to .so libs wich are time critical.
How to create parallel or detached processing using posix.
 

Hi,

So far i am happy with the insights tonight.

Source code:
rtapi_function_loader

Above is a repository testing the posix pthread, running different .so libary functions named "test();".
It's more or less how the original rtapi workflow is.

This is tested ok with a base thread nano second : 25.000
And you can set the used cpu's. You can set it by  passing a cpu_list = {0, 1}; image missing /media/kunena/emoticons/smile.png

If you load 4 instances of the rtapi_function_loader class and assign each
instance to a different CPU (CPU 1, CPU 2, etc.),
each instance will run on its own dedicated CPU core,
ensuring that all 4 threads run in parallel without sharing CPU time. image missing /media/kunena/emoticons/smile.png

We have also a priority for the rtapi_function_loader's pthread in the value 0 up to 100. image missing /media/kunena/emoticons/smile.png

Ok, now next thing is maybe to look when, where and why we need to allocate shared memory blocks.

Hi,

Made a even bigger example how linuxcnc primairely works with rtapi and hal.

Why do we made this example?
Primairely to get more insight's how rtapi loads rt modules, how hal is used and how to setup hal environment.
How to connect hal pin's to each other, and how they are updated.

Specs:

- loading multiple linuxcnc instances. (function loader instances)
- Choose the cpu's to clamp on.
- Set prioriy
- Create multiple shared memory regions.
- Update hal pins over different shared memory regions.
- Create and update hal connection's like "net", but then also connect structure types.

example

Then i looked into the hal ethercat component code, and indeed, above code could implement
a edited version of the hal ethercat code.

Aciera post=313997 userid=25994Hm, as I understand it, this does _not_ give us multi thread gcode execution as that would require multiple parallel motion planners in the same linuxcnc instance. A single instance of linuxcnc cannot interpolate more than one tool path at the same time.

I could be wrong, but given the current API that linuxcnc is written on top of, this would likely require very deep work into the core of linuxcnc. AFAICT there are no tools in the API that can synchronize the threads for instance. Also the code appears to be heavily written for serial execution. What would probably need to happen otomh is that the api would need a way to have each thread run independently with a centrally controlled memory management cache to synchronize the various threads. so you would have a trajectory planner " all required code to execute motion" for each new instance of a aixs and have it run in it's own thread and then a central trajectory planner would keep the various thread in sync. 

at that point, it would probably make sense to port to a mulithreaded api that has c and c++ tools for this kind of work. Texias Instruments RTOS for there microcontrollers has this kind of capabiliy. Any newer x86 can do this easily if it is multicore. I am not super familiar with the ROTS version of the linux kernel that just sa release. But yes a multithreaded pi would be required bare minimum.

@Smc.collins,

That's more or less what's going on.

Maybe you could run multiple trajectory planners in lcnc. But still you have just one
shared memory region, and one interpreter.

Today the realtime example is tested on real hardware using ethercat bus.
This is source code looks like RTAPI & HAL,  but is coded entirely from scratch.
Purposing it can load multiple instances of rtapi & hal.

// Ethercat EK1100 & EL2124
ethercat code

// Qt gui
qt_code

// Rtapi & hal lookalike code to run the application.
function loader

This test was going very well.
The qt app has buttons to set the ethercat digital io's.
The function loader also  connect's the hal pins over different shared memory regions.

Preview of ethercat test:

www.youtube.com/shorts/sKFA5jFS64c