CIN Core / P4 incompatibility ?

Question

I have a problem with a simple reentrant CIN in LV 8.6. The CIN has been written and compiled with Visual C++ 2008 Express on a Core Duo PC with Win XP SP2. It only performs numerical calculations that refer to <math.h> functions, and the only other "includes" are windows.h, cvilvsb.h and extcode.h for some type definitions ("int16" + some which are DLL & CIN related).
The .lsb file loads correctly in LV and the CIN runs fine on many "recent" PCs (even Quad Core 2 with Vista 64). However on some other PCs the VI is broken, with the message that the CIN has no associated code. After some tests it appeared that this happens on 2 PCs with P4 processors (with XP SP3). I've always thought all these architecture were x86 compatible so no compatibility issues would arise. Is it wrong ? I mean, is it expectable to have CIN incompatibilities between these two platforms (Core Duo and P4) ?
If this is indeed the case, what should be done ? Recompile the whole Visual project on a P4 machine ? Or only process the compiled DLL to a .lsb file with the lvsbutil.exe post-build tool on a P4 machine ? Does that make any sense ?
Even if it is probably little useful, I join the LV 8.6 VI with embedded CIN.
Any help would be appreciated...
Vincent
Message Edited by Sci-Vi on 07-16-2009 05:32 PM
Solved!
Go to Solution.
Attachments:
cin.vi ‏35 KB

Answer 1

Sci-Vi wrote: 
I agree CINs are getting a bit old compared to DLLs, and for many situations I also prefer DLLs. But sometimes CINs are good for two aspects :
- we have mesured a faster execution (2 to 3 times, with same code, same compilation, same hardware - only transformed .DLL to .LSB and call as CIN object) in some very specific circumstances (high rate fast calculation on rather large amount of data). I cannot explain precisely why, but we have measured it...
- distribution of simple single VIs that need to execute some portion of C code can be easier, you don't need to always think about this "little" DLL file that must follow everywhere... Just send the VI by email, copy it anywhere, drop it in your code and it runs. I agree this last point is not so universal, as my question above demonstrates ! Portability definitely is an issue...
Speed differences between CINs and DLLs are most likely because CINs always work with native LabVIEW datatypes, while with DLLs you have the choice to use native datatypes or more common C datatypes for strings and arrays.
When using native datatypes your C code has to be very carful to use LabVIEW memory manager functions whenever it attempts to change anything about the size or whatever of such buffers but there is no overhead at all when passing data from LabVIEW to the C code and back. With C datatypes there is always some overhead when passing data from LabVIEW to C and back but you can work with normal C memory rules (caller always allocates all buffers and callee uses them as needed).
Technically a CIN is also a DLL under Windows 32 Bit, that is wrapped into a LabVIEW resource file and stored inside the VI. Whenever a VI with CIN is loaded into memory, LabVIEW extracts the code resource and writes the embedded DLL into the temproary directory and then loads that as a DLL. The difference with a normal DLL is that each CIN only exports one single entry point that gets called by LabVIEW for the various events such as (un)loading, (un)initilializing, and run.
So the only real benefit of CINs is that the C code resource is indeed not a seperate file as far as the distribution of the code is concerned. This could have been made into a real advantage if it would be possible to load a different CIN code resource into a VI for each platform that LabVIEW can run on, but that has never happened. For me this is in fact a real drawback as I have often external code that should run on multiple platforms. With DLLs/shared libraries this is easily done if you observe a few rules as described in my blog publications under http://expressionflow.com/author/rolfk/
Rolf Kalbermatter
Message Edited by rolfk on 07-22-2009 12:09 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions