LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Change of lvsbutil since LabView 8.2 ?

Hello all,
using LabView 8.5 I started to create a CIN, using VC++ 2008 Express, from this tutorial and the NI LabView Handbook "Using External Code in LabView". They both are very clear & easy to understand. There were some issues with the variables "$(ProjectDir)" and "$(OutDir)" in the Custom Build Step (which calls lvsbutil.exe), since $(OutDir) holds the full path to the output directory, not the relative one. This was fixed quickly.
But I still got an error with the Custom Build Step, despite all parameters were set properly. Now I realized, that the command line parameters of lvsbutil.exe changed (and significantly the size) with LabView Version 8.2. Now there seem all parameters need to be preceded by switches, such as "-c" "-t".  A must- parameter seems to be the -c <code name>, but what does it mean?
Playing around on the command line with lvsbutil always produced: lvsbutil: error building resource file: 1
But when I tried to build the lsb- file with the lvsbutil from LV 8.0, it worked as described in the tutorials. If lvsbutil of LV 8.2 is used with the command line switches set as following, it also works (Bold: output of lvsbutil):

C:\Program Files\National Instruments\LabVIEW 8.2\cintools>lvsbutil -c "SampleCIN" -t CIN -d "C:\Eigene Dateien\VC-Sources\SampleCIN\Debug"
LabVIEW resource file, type 'CIN ', name 'SampleCIN.lsb', created properly.

But this command line doesn't work with lvsbutil of LV 8.5! Anyhow, the command line help of both versions is the same. Since I can use the created .lsb (version 8.2) file with LV 8.5 VIs, this should be no real problem for my work, but what is going on there? Does anyone has a hint, how to use the lvsbutil.exe of LV 8.5? And what do the other parameters mean?

greets, Dave
Greets, Dave
0 Kudos
Message 1 of 13
(3,518 Views)


@daveTW wrote:
Hello all,
using LabView 8.5 I started to create a CIN, using VC++ 2008 Express, from this tutorial and the NI LabView Handbook "Using External Code in LabView". They both are very clear & easy to understand. There were some issues with the variables "$(ProjectDir)" and "$(OutDir)" in the Custom Build Step (which calls lvsbutil.exe), since $(OutDir) holds the full path to the output directory, not the relative one. This was fixed quickly.
But I still got an error with the Custom Build Step, despite all parameters were set properly. Now I realized, that the command line parameters of lvsbutil.exe changed (and significantly the size) with LabView Version 8.2. Now there seem all parameters need to be preceded by switches, such as "-c" "-t".  A must- parameter seems to be the -c , but what does it mean?
Playing around on the command line with lvsbutil always produced: lvsbutil: error building resource file: 1
But when I tried to build the lsb- file with the lvsbutil from LV 8.0, it worked as described in the tutorials. If lvsbutil of LV 8.2 is used with the command line switches set as following, it also works (Bold: output of lvsbutil):

C:\Program Files\National Instruments\LabVIEW 8.2\cintools>lvsbutil -c "SampleCIN" -t CIN -d "C:\Eigene Dateien\VC-Sources\SampleCIN\Debug"
LabVIEW resource file, type 'CIN ', name 'SampleCIN.lsb', created properly.

But this command line doesn't work with lvsbutil of LV 8.5! Anyhow, the command line help of both versions is the same. Since I can use the created .lsb (version 8.2) file with LV 8.5 VIs, this should be no real problem for my work, but what is going on there? Does anyone has a hint, how to use the lvsbutil.exe of LV 8.5? And what do the other parameters mean?

greets, Dave



The bad lvsbutil for LabVIEW 8.5 is a known issue. They messed that up somehow and it seems not to work at all. Just use the one from LabVIEW 8.2.1. Hope they fix that for LabVIEW 8.5.1 although I don't really create CINs anymore. They really have no sngle advantage over DLLs anymore but quite some disadvantages.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 13
(3,496 Views)
Here is the official KB entry about this issue. NI is commited to fix this issue and we have targeted 8.5.1 to implement the fix. I can't give a 100% commitment that 8.5.1 will contain this fix, but the chances are very high.

I agree very much with Rolf's recommendation about using DLLs rather than CINs. In fact CINs are primarily there for compatibility reasons and should be avoided in new projects if possible.

Regards,

Jochen Klier
National Instruments


Message Edited by Jochen on 02-20-2008 09:34 AM
0 Kudos
Message 3 of 13
(3,485 Views)
Hello Rolf, hello Jochen,
thank you both for your quick answer. So from your advise I will try to solve it with a DLL.
greets, Dave
Greets, Dave
0 Kudos
Message 4 of 13
(3,469 Views)

CIN has great advantage, it can take control even if a parent VI is not running. Using extra entries like CINLoad, CINUnload, CINInit, CINDispose, etc. it has an opportunity to initialize some resources and release them depending on VI stage. Also, each CIN instance has its own unique data space (4 bytes value) that is usefull to identify the instance or store a pointer to dynamically allocated memory specific for the instance. All this together is great mechanism to embed external code into reentrant and multi-thread ready VIs.

kind regards

 

Message 5 of 13
(3,359 Views)


@kostya wrote:

CIN has great advantage, it can take control even if a parent VI is not running. Using extra entries like CINLoad, CINUnload, CINInit, CINDispose, etc. it has an opportunity to initialize some resources and release them depending on VI stage. Also, each CIN instance has its own unique data space (4 bytes value) that is usefull to identify the instance or store a pointer to dynamically allocated memory specific for the instance. All this together is great mechanism to embed external code into reentrant and multi-thread ready VIs.

kind regards



You have the same for shared libraries too. DllMain() for Windows DLLs and ini/fini for Unix shared libraries give you the possibility to do initialization on library load and uninitialization on library unload.

The rest of the CINxxx functions are very exotic and not understood by most people, and are almost never used.

Remains the fact that CINs are legacy technology and will go away sooner or later. Trying to rely on them for new developments is shooting in your own foot.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 13
(3,347 Views)

CINxxx entries are called for each CIN instance (at least CINInit/CINDispose), while DllMain for only entire DLL. This is a big difference! I agree about most of programmers don't use this (=CIN) features, but it does not mean CIN has no right to be live. Again, CIN is great mechanism for making advanced LV programming, and it provides advantages unreachable with DLL.

kind regards,
Konstantin Shifershteyn

 



Message Edited by kostya on 03-29-2008 10:51 PM
Message 7 of 13
(3,333 Views)


@kostya wrote:

CINxxx entries are called for each CIN instance (at least CINInit/CINDispose), while DllMain for only entire DLL. This is a big difference! I agree about most of programmers don't use this (=CIN) features, but it does not mean CIN has no right to be live. Again, CIN is great mechanism for making advanced LV programming, and it provides advantages unreachable with DLL.

kind regards,
Konstantin Shifershteyn

Message Edited by kostya on 03-29-2008 10:51 PM


Not in 8.5 anymore! The callback setup in the Call Library Node Configuration dialog is exactly meant to provide that sort of functionality.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
Message 8 of 13
(3,320 Views)

I am running LabView 8.6 and getting the same issue. I click on the link marked here and it was dead. I would like to use the CIN for a project I am doing.

0 Kudos
Message 9 of 13
(2,233 Views)

@JJM57 wrote:

I am running LabView 8.6 and getting the same issue. I click on the link marked here and it was dead. I would like to use the CIN for a project I am doing.


Why? Save yourself some headache and grey hair and simply develop a DLL! CINs are dead! They offer no advantage over DLLs anymore but several disadvantages. And if you ever plan to move to a newer LabVIEW version and 64-bit they won't work anymore and there is no officially supported way to create them for 64-bit LabVIEW (or LabVIEW for Mac OSX or any of the modern realtime targets).

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 13
(2,214 Views)