CIN or DLL

[prashant_bhutani]

Hi all,

I am doing a summer project in which I have to pass clusters to LabVIEW.

Since I have to pass am image so one data type is common to each cluster

,i.e., a dynamic array (signifying image) which needs to be resized according to the size of image.

I am a novice to labVIEW (just started one week ago).

So What do you people suggest whether I should go with DLL or CIN to pass the cluster to VI??

Reason for pointing this question:

http://zone.ni.com/r...s_vs_clf_nodes/ says

"You can pass arbitrarily complex data structures to and from a CIN.

In some cases, you might have higher performance using CINs because

data structures pass to the CIN in the same format that they are stored in LabVIEW."

while other documents/forums says that

"It is quite difficult to pass a structure containing an array/string to LabVIEW (which is the case with DLL)".

Please do tell me because my mentors have never used CIN.

Also, they never passed any cluster containing array/string as its member using call library nodes.

Thanks in advance

Edited May 25, 2010 by prashant_bhutani

[Rolf Kalbermatter]

Reason for pointing this question:

http://zone.ni.com/r...s_vs_clf_nodes/ says

"You can pass arbitrarily complex data structures to and from a CIN.

In some cases, you might have higher performance using CINs because

data structures pass to the CIN in the same format that they are stored in LabVIEW."

while other documents/forums says that

"It is quite difficult to pass a structure containing an array/string to LabVIEW (which is the case with DLL)".

You mix two very different things together here.

The first sentence is in fact a little outdated and only telling you half the truth although technically still correct.

Because you can pass LabVIEW native datatypes to DLLs since about LabVIEW 5 too. That is when they added the "Adapt to Datatype" to the Call Library Node and since then the CLN is in fact equivalent in this aspect to CINs.

So the sentence is right that CINs get the native data passed to it but forgets to mention that that is possible with CLNs too, and this sentence is in fact a remainder from the time when CLNs indeed did not have that option, due to system limitations in the at that time supported platforms including the Windows 3.1 and Mac OS Classic versions of LabVIEW.

The second talks about structures containing C array pointers which you can get sometimes when calling existing shared library APIs. Since LabVIEW does not represent arrays and strings as C pointers there is no simple way to create such structures in a LabVIEW diagram. But if you do create the DLL yourself, you are of course free to define the type of your function parameters and in such a way can use the LabVIEW native datatypes for your shared library function parameters by choosing Adapt to Type. This is an choice you do not have at all with CINs as they ALWAYS receive the parameters as native LabVIEW datatypes.

So it is not that CINs give you something you do not have with the CLN too, but that the CLN also allows you to call many API functions directly that use C array and string pointers as parameters. But this only works if the C pointers are directly function parameters, not when they are embedded inside clusters you pass to the API.

As last remark a handy trick when creating CLNs using the Adapt to Type feature or any of the LabVIEW native datatypes such as String and Array Handles:

1) Wire up the Call Library Node with the datatypes you want it to have

2) Right click on it and select "Create .c File"

3) In the file dialog select a file name to write to and LabVIEW will write a C prototype with all necessary parameter typedefs and the extcode.h include to disk so you can go on and copy/paste it into your C source code to be sure to start with the right prototype.