LabVIEW
How to run a shared object file built from C++ object-oriented source code on Call Library Function Node?
That's for sure possible but won't bring you around the problem of getting this function into the shared library and call it from LabVIEW. As long as you can't make the funcitons from IpStdCInterface show up and call them, you are just trying to solve the unsolved problem by running around it counter clockwise instead of clockwise.
Dear Rolf,
Thank you for your time. I have a few questions would like to ask you. But first, let me show you what I did.
The source code indeed needs various dependencies to get compiled (some solvers such as mumps, metis, lapack, and some were written in FORTRAN). So, I compiled the project in a 32-bit 14.04 LTS Ubuntu machine (i686, Oracle Virtualbox). It resulted in libipopt.so. I copied generated libs to sbRIO 9627. I ran the readelf command for the library and it gave me the below:
Then, I dug deeper by running readelf for libcoinmups.so. It gave me:
You can see, libgfortran.so is on the above list. I research how to install gfortran: (https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/Installing-gFortran-Compile-Tools-on-NI-Linux-...). But it seems this is for a 64-bit system. So here are my questions:
1. Is libgfortran is a 64 bit library even I compiled on a 32-bit system (Oracle VirtualBox)? The link of how to install gfortran above is for cRIO 9039 (apparently a 64-bit one). Mine is sbRIO 9627, how can I install FORTRAN for it? I did lots of research but could not find out. I also checked NI's opkg feed (http://download.ni.com/ni-linux-rt/feeds/). But I am not sure it has packages to install gfortran or fortran 77.
2. Do you think compiled in a 32-bit Ubuntu system (14.04 LTS Oracle VirtualBox) will cause any problems if I deployed the compiled libs to 32-bit NI RT Linux? I saw some differences from the NI RIO's libraries with the 32-bit Ubuntu system. One of those is when I use command objdum -TC liblapack.so, it showed:
Thank you very much.
Bests,
-P
@Peter_HP wrote:
Dear Rolf,
Thank you for your time. I have a few questions would like to ask you. But first, let me show you what I did.
The source code indeed needs various dependencies to get compiled (some solvers such as mumps, metis, lapack, and some were written in FORTRAN). So, I compiled the project in a 32-bit 14.04 LTS Ubuntu machine (i686, Oracle Virtualbox). It resulted in libipopt.so. I copied generated libs to sbRIO 9627. I ran the readelf command for the library and it gave me the below:
WRONG! And we've gone through that before! Your sbRIO 9627 is an ARM based system. You need a compiler toolchain that generates code for an ARM CPU target. The fact that your Ubuntu system is 32 bit does not matter, no matter that the ARM CPU also uses 32-bit mode. The x86 compiled object code from your Ubuntu development system is complete garbage for execution on the ARM CPU of your target. Assuming that the x86 created code should work on the sbRIO because they are both 32-bit is similar to expecting that the motor of a Ford car should fit into a Jeep simply because both have 4 wheels.
You need to either compile everything on the sbRIO itself after installing the development tools or install a cross compiler toolchain on your computer (Virtual Machine or not) and create everything there. But I'm sorry to say that you got yourself way over your head with this. The fact that your library also contains fortran dependencies simply turned this exercise from a pretty hard to solve one into a nightmare. This makes it not enough to just install the GCC toolchain itself, you also need to add the Fortran and whatever backends too. And you most likely can't just use the make (or cmake or whatever) scripts that comes with that project. These scripts need to be prepared to deal with the intricacies of a particular toolchain and version and it's highly unlikely they will work with the specific version need to do this crosscompilation without at least some fiddling and possible with a lot more than just some fiddling. This is definitely above my hat to even start trying to support and more than likely above yours too! Make scripts logic is one of the hardest to comprehend and almost impossible to master. It requires a lot of experience and some really around the corner thinking and that is just not something I want to spend my time with.
libgfortran.so most likely simply is the Fortran runtime support library, just like libc.so is the C runtime support library and libcxx.so is the C++ runtime support library that comes with the according compiler toolchains. Some of the other are likely also standard support libraries that you won't need to compile yourself if you are able to find the opkg for that library for your target. Which package that could be is a very interesting game of guessing.
But unless I have some real incentives in the form of a professional project for which I would need that, I"m not prepared to spend the days of labour this will definitely require to make this work for the NI Linux realtime targets. Sorry!
@Peter_HP wrote:
Thank you very much for your constructive comments. I've learned a lot from those. Also, I did not expect you to spend your time doing the compilation but your experience to comment on the direction that I am going. I really appreciate that.
Some kudos seem appropriate. You can give them too, and they are completely free to give!
Seems you already kudo-d most of his posts (it is Monday morning), so I'll add a few as well.
Search LabVIEW like a graph! One link that might eventually get you a little further, assuming you do everything on the sbRIO itself after having done
opkg update && opkg install packagegroup-core-buildessential git
could be: http://other.dreamrunner.org/en/2011/11/install-blaslapackitpp-on-usrp-e100angstrom-linux/.
It's not for the NI Linux RT system but the also opkg based Angstrom distribution which NI Linux RT is basically a sibling of.So while it might not exactly work letter by letter the same, it should be pretty close.
Once you compiled lapack and friends that way and installed them onto the system too, your also on the system compiled shared library should be possible to be loaded on that system.
Of course (OT), using native LabVIEW (optimization and linear solving) routines could be considered as an option.
wiebe@CARYA wrote:
Of course (OT), using native LabVIEW (optimization and linear solving) routines could be considered as an option.
Very true! And if my name was altenbah, that would be the way I always certainly would do. 😀
As it stands porting non trivial mathematical analysis functions between environments can be sometimes just as difficult and intimidating than interfacing low level C libraries. 😀
For me one of them has a somewhat higher probability to end up with a working solution, provided I know that the underlaying library is working perfectly, which of course is another challenge to determine.
Dear Rolf,
Thank you very much for providing me the link. (Caution: This reply I am writing may have multiple topics as I wanted to understand Call Library Function Nodes and I make lots of tests to test the bad boy). I am writing my issues and I hope you can comment on them.
Topic 1: I followed the link you provided. But I could not implement the first command (opkg install gfortran libgfortran libgfortran2). My sbRIO said: Couldn't find anything satisfy 'gfortran'. Actually, I have problems with installing it before. I also read the thread (https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/Installing-gFortran-Compile-Tools-on-NI-Linux-...) and it suggests to download gcc-4.8.3.tar.gz. Apparently, the device used cRIO 9039 was a 64-bit (again, mine is 9627 32-bit NI Linux). But I tried to follow to see what would happen. When I made the tar command, my device showed signals of full of memory. I also searched for NI's feed (http://download.ni.com/ni-linux-rt/feeds/). But I have no clues what .ipk I should install to have gfortran or does NI have such kind of thing. The command you sent me:
opkg update && opkg install packagegroup-core-buildessential git
It seems the above command does not have gfortran. Could you comment how to install gfortran? I remember you said picking up the right package is interesting of guess.
Topic 2: I am testing the Call Library Function Nodes. I want to see how dlopen() and dlsym() calls behave. I am still sticking to optimization tasks and I wrote a simple optimization problem using 'fmincon'. Actually, for my optimization problem, the open-source ipopt had a better performance than 'fmincon', quite much. That why I am still trying to compile the open source. Here is the MATLAB code:
function xOp1 = OE(a)
A = [];
b = [];
Aeq = [];
beq = [];
lb = -2;
ub = 2;
opts = optimoptions('fmincon','Algorithm','sqp','MaxIterations',50,'OptimalityTolerance',1e-5,'Display','none');
x0=1;
xOp = fmincon(@m_f,x0,A,b,Aeq,beq,lb,ub,[],opts);
xOp1 = xOp+a;
end
function [c,ceq] = unit_d(x)
c = x(1)^2 + x(2)^2 - 1;
ceq = [];
end
function f = m_f(x)
f = x^2 + 2*x + 1;
end
You see the code quite simple and MathScript in my sbRIO easily beat it up. Now I converted the code to C by MATLAB coder. I selected Hardware Board Arm-Cortex A9 (QEMU) and Linaro Tool Chain 4.8. The C code was generated smoothly. I used the code and compiled it on Eclipse for 32-bit NI Linux to create a shared library. No errors even a warning. However, when I deployed it to the RIO. But I continuously got the message: Warning: Connection to the target (target) has been lost. Here is the screenshot taken from the command readelf -d:
Do you think any issues with the program? Why MathScript did the problem a bit easily, the Call Node Library had issues?
Thank you very much.
Bests,
-P
The SQP wiki mentions LabVIEW has this implemented.
This solution need the Control Design and Simulation Module:
https://zone.ni.com/reference/en-XX/help/371894J-01/lvsimconcepts/sim_c_executesqp/
This one doesn't:
https://zone.ni.com/reference/en-XX/help/371361R-01/gmath/constrained_nonlinear_optimization/
Not sure if\how it will work on a cRIO. Not sure in general how it works. It's not the same as the function you're using, but might still do the trick.
