How do .comp files work?

(This is a programming discussion and I'm not sure which forum to post it in)

Newbie here just trying to learn how everything interacts. At the moment I'm studying the plasmac.comp file that @phillc54 wrote:
github.com/phillc54/linuxcnc-plasmac/blo...ponents/plasmac.comp

I do have pretty basic programming experience as a hobby dabbling here and there over the years. That does include some gnu c/c++.

To this point I've been using this doc to help get my bearings.

Questions:
So, I gather a .comp file is a specialized c file. Is it just specifically something used by linuxcnc? Or is .comp a standard filetype for the gnu compiler?

The plasmac.comp file appears to be just one big unnamed function, with most of the logic in one big switch statement on a machine state variable. How does the linuxcnc system call this function? I guess it has to be called from a loop somewhere. How fast is this loop called? Is there a chart somewhere that illustrates the order of execution, precedence, etc.?

Does a FUNCTION(_) not use a return variable?

AgentWD40 wrote:

(This is a programming discussion and I'm not sure which forum to post it in)

Newbie here just trying to learn how everything interacts. At the moment I'm studying the plasmac.comp file that @phillc54 wrote:
github.com/phillc54/linuxcnc-plasmac/blo...ponents/plasmac.comp

I do have pretty basic programming experience as a hobby dabbling here and there over the years. That does include some gnu c/c++.

To this point I've been using this doc to help get my bearings.

Questions:
So, I gather a .comp file is a specialized c file. Is it just specifically something used by linuxcnc? Or is .comp a standard filetype for the gnu compiler?

The plasmac.comp file appears to be just one big unnamed function, with most of the logic in one big switch statement on a machine state variable. How does the linuxcnc system call this function? I guess it has to be called from a loop somewhere. How fast is this loop called? Is there a chart somewhere that illustrates the order of execution, precedence, etc.?

Does a FUNCTION(_) not use a return variable?

Thats a component. A component is a real time module that gets loaded with loadrt in the hal file. They have pins, parameters, functions and data that can be accessed in HAL.

Is that what your looking for?

Perhaps this might help? Hal Component

The comps function call is setup by the:

addf somecomp somethread

line in the hal file

bevins wrote:

Thats a component. A component is a real time module that gets loaded with loadrt in the hal file. They have pins, parameters, functions and data that can be accessed in HAL.

Is that what your looking for?

No, but thank you. I have that understanding of what a component is. Per the questions in the op I'm looking just for a few specifics.

Perhaps this might help? Hal Component

That looks like another version of the doc I linked to in the op.

Hi Kyle,

So, I gather a .comp file is a specialized c file. Is it just specifically something used by linuxcnc? Or is .comp a standard filetype for the gnu compiler?

A .comp file is indeed a specialized c file.
If you compile a .comp file into a .c file you will see it a huge code for coupling hal side logic.

The process is explained over here : linuxcnc.org/docs/2.5/html/man/man1/comp.1.html
Section : Preprocess .comp files into .c files (the --preprocess flag)
I used this preprocess function in the past to look how some things are done in raw c code.

The plasmac.comp file appears to be just one big unnamed function, with most of the logic in one big switch statement on a machine state variable. How does the linuxcnc system call this function? I guess it has to be called from a loop somewhere. How fast is this loop called?

The plasmac.comp (c-code) goes into machine code by compiling it into plasmac.so
At this moment it can be inserted in the real time kernel. In fact it looks like the insmod function.
Linux read's at startup the ini and hal files. It load's the list file by file. So it loads the plasmac.so at the specefic hal line.
This loop is as fast as the kernel loop if you use the base thread. Servo thread is slower, but fast enough for this function my dear.

Is there a chart somewhere that illustrates the order of execution, precedence, etc.?
You can make your own chart. I have atteched source code for this to visualize.

A compile example :

sudo halcompile --compile plasmac.comp => wil give you plamsac.so in same directory (otherwise use the --install flag)
sudo halcompile --preprocess plasmac.comp => will give you plasmac.c

The order of execution of real time comps (attached to a given thread) is the addf order in
the hal file, though you can change this default order with a sequence number appended to the addf line:

addf somecomp somethread 3

Grotius wrote:

Hi Kyle,

So, I gather a .comp file is a specialized c file. Is it just specifically something used by linuxcnc? Or is .comp a standard filetype for the gnu compiler?

A .comp file is indeed a specialized c file.
If you compile a .comp file into a .c file you will see it a huge code for coupling hal side logic.

The process is explained over here : linuxcnc.org/docs/2.5/html/man/man1/comp.1.html
Section : Preprocess .comp files into .c files (the --preprocess flag)
I used this preprocess function in the past to look how some things are done in raw c code.

The plasmac.comp file appears to be just one big unnamed function, with most of the logic in one big switch statement on a machine state variable. How does the linuxcnc system call this function? I guess it has to be called from a loop somewhere. How fast is this loop called?

The plasmac.comp (c-code) goes into machine code by compiling it into plasmac.so
At this moment it can be inserted in the real time kernel. In fact it looks like the insmod function.
Linux read's at startup the ini and hal files. It load's the list file by file. So it loads the plasmac.so at the specefic hal line.
This loop is as fast as the kernel loop if you use the base thread. Servo thread is slower, but fast enough for this function my dear.

Yay, I get it! Thank you so much!

Is there a chart somewhere that illustrates the order of execution, precedence, etc.?
You can make your own chart. I have atteched source code for this to visualize.

Whoa, I asked for a chart and I got one! So if I were to run that python script on my machine it would dynamically generate that diagram based off of how my machine is currently configured? (I'm not at my linuxcnc machine right now)


Okay, so looking at the basic hal tutorial: You use loadrt to load the component, like importing a library in c like #import <>. Then you call addf to initialize it however many times you need it, kind of like a c++ object. Right? But in the case of the plasmac it's a "singleton" so it can only be intialized once.

... I think it's starting to come together.

@Pcw,

That option sound's to me like a goto function. It sound to me like a repair function for a not logic program flow.
Function's like a goto are not used by good programmers.

In fact if you add a sequence number for components to load, the program is running again and again until it finds the following number.
The fastest and natural (KIS (keep it simple)) way is to write down your cycle in hal from the top to bottom.

Umm, no...

The issue is that the strict hal file ordering fails when you have addf's in multiple hal files
but need the function sequence to be different than the hal file parse order

@Kyle,

Whoa, I asked for a chart and I got one! So if I were to run that python script on my machine it would dynamically generate that diagram based off of how my machine is currently configured?
It's visualizing complex environment's, just like the most complex toma.thc files in this case. And done some improvement's because that is not possible without this view diagram.

You can google on dot.py how to use this old stuff. It's old and almost gone from the net, but the power of this python script is nice.
Maybe post it on the Git....

In what code is "option singleton" converted into when compiled from comp to raw c?
The preprocess compiler will change this i expect into some other c code.

@Kyle, The singleton line is not important in your case at this moment. There are much more option's to use with the compiler.

@Pcw,

The issue is that the strict hal file ordering fails when you have addf's in multiple hal files
I agree.