07-12-2017 05:26 AM
Hello,
I have a project with different applications. It's programming in C. How can I import the complet project into LabVIEW? I saw that we can import .so files but me, I want to import a complet project which containts different applications which are modular. I don't want to create a .so file for each application because I have a lot of them and it will be take a long time. There are a lot of links between these applications. So, please help me.
Thanks,
07-12-2017 08:03 AM
Speaking very shortly - you can't. LabVIEW is a graphical programming language and it is not able to "import" your textual codes. You need to compile those C apps into shared libraries (.so / .dll) to work with them in LabVIEW. Another option here might be IPC (inter-process communication) between your C apps and LabVIEW by means of things as TCP/IP, UDP, SV, Pipes, Shared Memory or something else.
07-12-2017 08:25 AM
Thank you for your answer.
The problem is that you can just have one fonction in your shared librairies. But my application have several functions in differents classes. I need to get the full project written in C for not having to rewrite in LabView. I can not call each function one by one. On the basis of requests from an HMI, I call a particular class and it returns to me the parameters necessary for the display on the HMI. In addition, the parameters come to be saved in an XML file. So there are several interactions. So, I need to integrate the entire C project into LabView.
I will look for the IPC.
Thank you
07-12-2017 08:57 AM
@Roudoudou wrote:
Thank you for your answer.
The problem is that you can just have one fonction in your shared librairies. But my application have several functions in differents classes. I need to get the full project written in C for not having to rewrite in LabView. I can not call each function one by one. On the basis of requests from an HMI, I call a particular class and it returns to me the parameters necessary for the display on the HMI. In addition, the parameters come to be saved in an XML file. So there are several interactions. So, I need to integrate the entire C project into LabView.
I will look for the IPC.
Thank you
This really makes little sense to me. From what I'm reading, you have a nice C++ project (Possibly overcoupled code components but, working code right?) Now you want to "Google Translate" the entire code base from C++ to LabVIEW? I must be misunderstanding something in your post.
Can you help us help you by being a bit more specific about what you wish to accomplish? A simplified version of actual C++ and LabVIEW code would be very nice to have to help you.
07-12-2017 07:35 PM - edited 07-12-2017 07:41 PM
@Roudoudou wrote:
Thank you for your answer.
The problem is that you can just have one fonction in your shared librairies.
That's definitely not true. A shared library exports typically several dozen to several 100 functions.
But as others have already tried to explain you, there are more things with your explanation that don't really make much sense. If you want to call your C(++) code from LabVIEW you have basically three options:
1) add a C function interface to your C++ code that you can call through the Call Library Node and compile everything into a shared library. This typically means to write C function wrappers around every object method that you want to be able to call and in addition also a C function to create and destroy/delete each object.
2) translate everything into LabVIEW and no there are no automatic C(++) to LabVIEW converters
3) Create an application out of your C(++) code and add an IPC interface to it that you can connect to from LabVIEW.
Each of these options is some significant work.
07-13-2017 12:40 AM
rolfk wrote:
1) add a C function interface to your C++ code that you can call through the Call Library Node and compile everything into a shared library. This typically means to write C function wrappers around every object method that you want to be able to call and in addition also a C function to create and destroy/delete each object.
If the author is going to use 64-bit LabVIEW only it is not necessary to make such wrappers. On 64-bit Windows platform there's the Microsoft x64 calling convention, which uses registers RCX, RDX, R8, R9 for the first four integer or pointer arguments. When calling a C++ class methods, first parameter should be a class instance pointer and it is put into RCX when the func's entered. So, it's enough to pass a class pointer as first parameter in all functions that work with this class and it should work. (I tried this on my own in the past.) Yes, the funcs' names are mangled and they don't appear in CLFN's drop-down list, but you may write or paste them manually.
So, for 64-bit IDE the author just needs to export a constructor, methods and a destructor.
07-13-2017 01:39 AM
Thank you for your answers. I realized a small diagram that will allow me to better express myself. On this diagram is explained an example of what is realized in C currently. I would like to retrieve what was done in C in the database and put it in the SbRio via LabVIEW. So I wanted to know if that was possible and how.
07-13-2017 01:57 AM - edited 07-13-2017 01:58 AM
@dadreamer wrote:
rolfk wrote:
1) add a C function interface to your C++ code that you can call through the Call Library Node and compile everything into a shared library. This typically means to write C function wrappers around every object method that you want to be able to call and in addition also a C function to create and destroy/delete each object.
If the author is going to use 64-bit LabVIEW only it is not necessary to make such wrappers. On 64-bit Windows platform there's the Microsoft x64 calling convention, which uses registers RCX, RDX, R8, R9 for the first four integer or pointer arguments. When calling a C++ class methods, first parameter should be a class instance pointer and it is put into RCX when the func's entered. So, it's enough to pass a class pointer as first parameter in all functions that work with this class and it should work. (I tried this on my own in the past.) Yes, the funcs' names are mangled and they don't appear in CLFN's drop-down list, but you may write or paste them manually.
So, for 64-bit IDE the author just needs to export a constructor, methods and a destructor.
You still need to make sure all the methods are even exported. Normally object methods don't neet to be exported at all from a shared library. The only thing that needs to be exported are some form of object constructurs, or in the case of ActiveX or .Net a class factory. The rest is then automatically deduced by the C++ compiler from the header file and the necessary code is generated, but here the nasty things really start. There has never been a real standard about how the virtual table and object members should be layed out in memory. Maybe someone decided to make this a standard now for 64 bit but I kind of doubt it. It's one of the ways to make sure that if someone started with a particular C++ compiler he won't just simply be able to move to another one without recompiling everything in that new compiler.
And of course every "good" programmer has his ideas about how to squeeze a little bit more performance out of some code by putting stuff into memory in a certain way. So it may work but I would still be hesitant to rely on that across compilers.
If you get the C++ compiler to export all the member methods you want to call, then yes it could in principle work but I think the name wrangling alone is already a hassle that makes this not an attractive choice at all.