ecrt_support.c is not being found in the correct location
/usr/local/share/etherlab/src/ecrt_support.c (if CMAKE_INSTALL_PREFIX
was not set when calling cmake)
Instead it is being found at
$MATLAB/rtw/c/etherlab/blocks/EtherCAT/ecrt_support.c, which is wrong
because it is a 0byte file, just there to fool matlab because it looks
for the presence of this file during code generation.
Have a look at the generated makefile. What is $ETHERLAB_DIR? There is a
make rule
%.o : $(ETHERLAB_DIR)/@INSTALL_PATH@/src/%.c
$(cc) -c $(CFLAGS) $(GCC_WALL_FLAG) "$<"
(the fifth rule) which should find the required file.
Instead it is using the eighth make rule:
%.o : $(MATLAB_ROOT)/simulink/src/%.c
$(cc) -c $(CFLAGS) $(GCC_WALL_FLAG) "$<"
Somehow I suspect that the installation process went wrong:
# cd $ETHERLAB_SRC
# mkdir build
# cd build
# cmake ..
# make
# make install
# /usr/local/share/etherlab/install.sh $MATLABROOT
# matlab -r "run(strcat(matlabroot,'/rtw/c/etherlab/setup_etherlab.m'))"
Please zip the project folder and PM it to me.
As a quick fix:
You could copy ecrt_support.c it from /usr/local/share/etherlab/src to
Matlab $MATLAB/rtw/c/etherlab/blocks/EtherCAT, but that was not the
intention, especially in split code generation (i.e. host where matlab
is being run) and compile/execute (the real-time target) case.
------------------------------------------------------------------------
On 2020-04-06 18:10, Moritz Schappler wrote:
The remark on the external mode patch was perhaps misleading. To test
this I used the official versions of the mercurial repos and not the
patched version.
When comparing the output of `make VERBOSE=1 clean all`, it becomes
obvious that the argument "-lethercat" is missing to the g++ command in
R2019a.
Previous to that, in R2018b I have as part of the line
-Wall -W -Wwrite-strings -Winline -Wpointer-arith -Wcast-align
-Wstrict-prototypes -Wnested-externs -Wno-long-long
"/usr/local/share/etherlab/src/ecrt_support.c"
and in R2019a I have for the corresponding part just
/mnt/FP500/usr/local/MATLAB/R2019a/rtw/c/etherlab/blocks/EtherCAT/ecrt_support.c.
The compiler resolves my symbolic link for saving space in my root
directory:
$ ll /usr/local/MATLAB
lrwxrwxrwx 1 root root 27 Jun 24 2017 /usr/local/MATLAB ->
/mnt/FP500/usr/local/MATLAB/
So the file seems to be searched in the wrong place (matlab directory).
The full log is attached.
I am not sure if the missing "-lethercat" is related or a different
issue. When manually adding the "lethercat" to the command in the
terminal, the error remains.
The library can be found:
$ ld -lethercat --verbose
[...]
found ld-linux-x86-64.so.2 at
//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
ld: warning: cannot find entry symbol _start; not setting start
address
I currently have no access on a different machine for testing, so I
don't want to waste your time with what could be a problem specific to
my computer setup unaware to me.
I am currently on Ubuntu 18.04 (upgraded from 16.04). If someone else
could report the same error or show that it works, it could already help
a lot.
Thanks already
On 06.04.20 17:19, Richard Hacker wrote:
The file 'ecrt_support.c' in $MATLABDIR should be empty. It shouldn't
even be there, but matlab complains that this file is missing, thus
the 0Byte file.
The generated Makefile from etherlab_hrt.tmf, however, ensures that
the (non-empty) source file is found in $INSTALLDIR/src/ecrt_support.c
before $MATLABDIR/rtw/c/etherlab/src. (It could probably better have
been a link from $MATLABDIR to $INSTALLDIR)
You seem to be applying patches to use matlab's external mode and your
problem could be found there.
Try
make VERBOSE=1 clean all
in the generated directory to find out where ecrt_support.c is found.
On 2020-04-06 16:57, Moritz Schappler wrote:
Hello Richard,
thanks for the quick reply. The output of `nm ecrt_support.o` showed a
potential reason: It is empty and the underlying file
rtw/blocks/EtherCAT/ecrt_support.c in the Matlab directory is also empty
(0 bytes).
It seems, as if the file should be used from
/usr/local/share/etherlab/src with 44kB, but Matlab takes the wrong
file. Matlab R2018b also has the empty file, but seems to not take it.
I installed Etherlab for both R2018b and R2019a in the same way, using
install.sh and setup_etherlab.m:
https://github.com/SchapplM/etherlab-examples/blob/master/SETUP_ETHERCAT.MD#entwpc
Perhaps setting up the directories for linking the Simulink project has
changed in R2019a, or I messed up the Matlab path without having
noticed.
I re-tested on a different machine this time, though.
This duplicate 0B-file was already introduced in hg-commit 1146
(2018-02-08).
When I overwrite the 0B file with the full version in the Matlab dir, I
get similar errors. Instead of
new_2019a.o: In Funktion »new_2019a_step«:
new_2019a.c:(.text+0x15): Warnung: undefinierter Verweis auf
»ecs_receive«
I get something like
ecrt_support.o: In Funktion »ecs_receive«:
ecrt_support.c:(.text+0xa0b): Warnung: undefinierter Verweis auf
»ecrt_domain_process«
The output of nm ecrt_support.o` now gives for R2018b and R2019a
U calloc
U clock_gettime
[...]
U ecrt_domain_data
[...]
So the symbols are undefined ("U") also in the previous version R2018b.
Is it possible that the linker/compiler since R2019a is "stricter" and
now raises an error for the undefined references?
As for manually running the g++ command: Building fails with the same
error in R2019a and R2018b.
Therefore the path configuration only seems to work from within Matlab
(R2018b).
Up to now, the only manual adaptation to making the build process work
was symbolically linking the shared libraries in /usr/local/lib/ with
$ ll /usr/local/lib/
lrwxrwxrwx 1 root root 44 Apr 6 14:54 libethercat.so ->
/usr/local/share/etherlab/lib/libethercat.so*
lrwxrwxrwx 1 root root 42 Apr 6 14:56 libpdserv.so ->
/usr/local/share/etherlab/lib/libpdserv.so
I attached the detailed logs.
In matlab-mex of the setup_etherlab.m I got the warnings
Warning: You are using gcc version '7.5.0'. The version of gcc is not
supported. The
version currently supported with MEX is '6.3.x'. For a list of
currently supported
compilers see:
https://www.mathworks.com/support/compilers/current_release.
which could also be related to handling of warnings/errors, but did not
pose a problem in R2018b for instance.
Thanks already for looking into this.
Viele Grüße
Moritz Schappler
On 06.04.20 13:18, Richard Hacker wrote:
Hi Moritz
I do not have Matlab > 2017 available to test, but I do not see a
reason that ecs_*() symbols are not be found. They are defined in
ecrt_support.c which is compiled and linked.
Please go into the directory and supply me with the output of:
cd /home/schappler/IMES/REPO/ethercat/etherlab-slaves/ixxa
/new_2019a_etl_hrt
nm ecrt_support.o
Maybe try to compile the executable with (I just moved new_2019a.o
forward):
g++ -o ../new_2019a new_2019a_capi.o new_2019a.o new_2019a_data.o
new_2019a_header.o rtGetInf.o rtGetNaN.o rt_nonfinite.o ecrt_support.o
hrt_main.o -L/usr/local/lib -lm -lpdserv -ldl -lrt -pthread
Mit freundlichem Gruß
Richard Hacker
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users
