2.4. Building emc2 (realtime)
What was it?
John
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Elite Member
- Posts: 164
- Thank you received: 1
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?
Please Log in or Create an account to join the conversation.
The magic words are:
cd emc2-dev/src
./autogen.sh
./configure
make
sudo make setuid
John
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Elite Member
- Posts: 164
- Thank you received: 1
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?
Please Log in or Create an account to join the conversation.
John
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Elite Member
- Posts: 164
- Thank you received: 1
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
Please Log in or Create an account to join the conversation.
www.linuxcnc.org/docs/EMC2_Developer_Manual.pdf
I know that /scripts/emc starts all the process.
John
Please Log in or Create an account to join the conversation.
. Anyway the following can be put in a bash script so you don't have to keep typing it each time
The magic words are:
cd emc2-dev/src
./autogen.sh
./configure
make
sudo make setuid
No need for a bash script, as the autogen, configure and setuid lines only need to be done once per installation.
I compile with just "make".
Please Log in or Create an account to join the conversation.
- adelabarra
- Offline
- New Member
- Posts: 12
- Thank you received: 0
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
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.