LabVIEW
Other compilers for Code Interface Networks (CIN's)
@CalTech wrote:
Hello,
I was wondering what kind of compilers would compile the a program written in C code. But that would do so so that the compiled program is compliant with the LabVIEW and the CIN. According the manual it recommends Visual C++ and Symantec, but are there others? Like free ones online that would be the right format? I notice there are alot of free ones online and I even use one of my own but what are the specifications etc.
Thanks,
Brian
In general a LabVIEW CIN on Windows is a DLL with a specific number of functions exported. This DLL is then wrapped into a code resource by the LVSButil.exe tool which comes with the cintools. So as far as that is concerned any C compiler, linker being able to create DLLs would theoretically work. The crux lies in the fact that the provided link libraries you absolutely necessarily need to create a CIN compatible DLL only come in two formats. One is the Microsoft binary object format (COFF) and the other is the Symantec binary object format (OMF). As such only C linkers understanding one of these two formats can possible create a DLL which can be turned into a CIN resource.
A list of possible compilers:
LabWindows CVI can create CINs as it supports both COFF and OMF object file formats.
Borland 4.5 (not sure if that is the free version but I doubt it) can read OMF files and therefore should work with the Symantec libraries but I never tried that.
Watcom 10.x should work with the COFF libraries for function exports but may have problems with importing exported variables in some cases. The current open source Watcom C compiler based in part on this older version should probably be able to get you somewhere.
MingW might be the best shot at trying to use a free C compiler. It should be fairly Microsoft compatible in many ways so that it might link with the COFF libraries provided without problems.
However expect to really dig into the makefile necessary to create CINs properly both for Watcom C and MingW. If you have not a good understanding of the MingW toolchain and the underlying gcc compiler or the Watcom system this may just be an exercise in vain. I personally don't venture to try to get this working.
Basically you will have to try to get a DLL compiled with the appropriate cintools libraries linked in such as the labview.(sym.)lib for any LabVIEW manager functions, the lvsb.(sym.)lib and cin.(sym.)obj for proper CIN support and lvsbmain.def or whatever your compiler will need to define the apropriate exports LabVIEW expects to see in the CIN DLL.
Then invoke lvsbutil.exe as seen in the ntlvsb.mak file to turn the created DLL into a CIN resource and cross your fingers that LabVIEW can load that CIN resource without complaining or crashing.
Rolf Kalbermatter
I forgot to mention, that creating DLLs as suggested by Dennis and using them trough the Call Library Node instead is indeed a much more promising path to go down. In DLLs you can basically do anything you could do in a CIN expect some very rare and advanced things, have the choice of the tools you want to use to create your DLL and are isolated from all complications of LabVIEWs unique CIN architecture.
Also CINs are not possibly multiplatform in the sense that you can't create a VI containing a CIN you could load on any LabVIEW platform without manual interaction.
With the Call Libary Node if you are careful to write the code in a way which can be recompiled into a shared library/DLL on any platform you want to use it from LabVIEW, and make sure all functions are always exported as cdecl, you just have to define the library name in the CLN as.* and LabVIEW will link automatically to the proper shared library file for whatever platform the VI was loaded on.
Rolf Kalbermatter
Also CINs are not possibly multiplatform in the sense that you can't create a VI containing a CIN you could load on any LabVIEW platform without manual interaction.
With the Call Libary Node if you are careful to write the code in a way which can be recompiled into a shared library/DLL on any platform you want to use it from LabVIEW, and make sure all functions are always exported as cdecl, you just have to define the library name in the CLN as
Rolf Kalbermatter
@rolfk wrote:
you just have to define the library name in the CLN as.* and LabVIEW will link automatically to the proper shared library file for whatever platform the VI was loaded on.
Grr, stupid HTML code. This sentence should read:
you just have to define the library name in the CLN as (name).* and LabVIEW will link automatically to the proper shared library file for whatever platform the VI was loaded on.
Rolf Kalbermatter
