Why does MOTMOD create its own threads?

Hi all,

This question is coming from me trying to better understand motmod. What about motmod makes so that this comp needs to create and manage its threads instead of having the "threads" module handle setting up threads and then loading motmod after?

So far I understand that threads need to be loaded in a particular order (fastest to slowest) and that motmod also ensures that the base and servo thread are integer multiples of each other. Besides this what other things does the motion planner need to guarantee about its threads to work properly?

Motmod is a component like tpmod.
rtapi creates posix threads. Rtapi does not care about thread speeds. Each posix thread calls a list off components. Then rtapi calls a function order into the component itself with dlopen...

motmod does not create threads.
motmod is a trajectory planner coordinator and supervisor.

 

If you read it like that you think its modmot loading threads. But reality is different.
rtapi creates the threads.

 

Ok, so it would be reasonable to assume that if I moved the rtapi call from motmod/tpmod to somewhere else I should not expect weird side effects since this is all done through the fairly standard RTAPI API.
One other question I have is, why is there a limit on the # of threads created and the order they are created in? Is this again a convenience/limitation made to simplify things or more of a deliberate design trade-off?

Hi,

To understand the function call flow from rtapi to components i made a compact example a while ago.
This is a universal approach, same as lcnc uses:
function loader

Normally you can just create new thread. This one uses a json file to load threads, shared mem, components.
new thread

Ok, so it would be reasonable to assume that if I moved the rtapi call from motmod/tpmod to somewhere else I should not expect weird side effects since this is all done through the fairly standard RTAPI API.
The dlopen call from rtapi is straight into the component motmod or tpmod lib's function.
You can not move it around, but you can create logic to manipulate or change rtapi calls.

One other question I have is, why is there a limit on the # of threads created and the order they are created in? Is this again a convenience/limitation made to simplify things or more of a deliberate design trade-off?
I did not know this but in terminal : ulimit -a
Is the limit of posix threads for users. Admins may do more.