2.4. Building emc2 (realtime)

You we right on. It was the NML_FILE = emc.nml in the my-mill-2 ini file
when I commented it out and typed the magic words
me@CNC:~$ cd emc2-dev
me@CNC:~/emc2-dev$ . ./scripts/emc-environment
me@CNC:~/emc2-dev$ emc

Evey thing started to work. I'm now wondering when I modify a c file will linux
compile all the untouched files or just the one i worked on?

Thanks making a script will save some typing. What I was thinking is that old UNIX had
a built in utility such that when it would automatically not compile code files that had not been
modified "touched" thus making the process faster.

If Linux dose not have this feature is it worth the trouble to modify the make file and or
other files that direct the compile and link process?

Super that should save some time, I was able to brew a cup of tea during the first compiled of emc.

I am now trying to understand how information in the my-mill.ini file is made available to C routines
in particular interp_convert.cc. Variables like TOOL_CHANGE_QUILL_UP are accessed in C statements such as " if (settings->tool_change_quill_up) { " in the interp_convert.cc code.

Suppose I wish to create my own variable names in the ini or access disk files like tool.tbl
and use them in the C routines, interp_convert.cc seems to lack a file open statement so this
must happen else where and tool_change_quill_up appears as some kind of local or a global variable.

Also I would like to understand how Hal and C variables communicate. Hal components written
in C are converted into KO files. The variables within are some how accessed by other routines.

Where can information on how this works be found?

Thanks

Hello
I ve got a similar problem.
So the only I could discover is a chain of dependencies as follows

First load module rtai_hal.ko
then rtai_up.ko
then rtai_fifos.ko
then rtai_shm.ko
rtai_sem.ko
and finally rtapi.ko

May be the system tries to load rtai_shm.ko, but if it is loaded it will reject and abort the init.
Then you can start again with the rtai_shm.ko unloaded.

There is where i ve just arrived.
I ve got another rejected modules (motmod.ko) ahead and if you have any clue where to follow I tank in advance.
Regards.
Alejandro

garymcrobertpdx wrote:

I am now trying to understand how information in the my-mill.ini file is made available to C routines

Suppose I wish to create my own variable names in the ini or access disk files like tool.tbl
and use them in the C routines, interp_convert.cc seems to lack a file open statement so this
must happen else where and tool_change_quill_up appears as some kind of local or a global variable.

Also I would like to understand how Hal and C variables communicate. Hal components written
in C are converted into KO files. The variables within are some how accessed by other routines.

Where can information on how this works be found?

Largely by digging through the source code.

Realtime modules cannot do file I/O using the normal stdio.h file functions, they are kernel modules.

Parsing of the ini file is specifically catered for ( see inifile.h and inifile.hh and .../src/emc/ini for starters).
When linuxcnc is started it has commandline argument(s) first of which is the inifile.
The processes launched thereafter are either passed those arguments in argc, argv fashion or query the running process for the inifile name and can access the ini file also

The modules (.ko) created can access the buffers in the linuxcnc process such as command and status, obtain the mutex lock to examine data in pins etc, but are standalone units, other routines can only access the data that they expose via their pins.
Think of them as C++ classes, the internals of them are hidden and data can be obtained via their methods / functions (pins)

That is a very potted guide to just the areas you raised, the subject itself is huge and takes a lot to get your head around.

Best place to start?
I started by disassembling xemc.cc. It is a GUI, but under that are all the calls etc required to create a new emc sub-process, register with the running main process etc etc
halcmd will show creating pins and interogating them.
Look at that and all the headers that they use and you will gain some form of enlightenment, even if it is just a notion of the size of the fog bank ahead of you !

regards