[etherlab-users] Limitations on Matlab Version - R2018b vs R2019a

Tue Apr 7 10:30:01 CEST 2020

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
>>>>
>>>
> 