CIN vs. Call Library Function

[YohanShminge]

Hi Everyone,

I'm working on developing LabVIEW interfaces for some data acquisition hardware.  I have libraries in Linux that I've tested with a CIN.  However, I need to separate the CIN code into two (or more) blocks.  One of them initializes the DAQ device, the other reads data from it.  This has to be done because I don't want to re-initialize the device every time I need data (since this takes time).  My problem is how to link the two CINs.  The device initialization returns a pointer to a struct.  A fairly big and complex struct.  How do I handle passing this struct to the next CIN?

Alternatively, I just tried using the Call Library Function block.  I can load up the library and pick my functions fine.  However as soon as I close the CLF dialog box I get an error about an undefined parameter.  I think labview is looking for another required library (having to do with the USB interface).  Is there some way I can instruct LabVIEW to look for this library?

Thanks for your help!

 -Yohan

[rolfk]

---

YohanShminge wrote:

Alternatively, I just tried using the Call Library Function block.  I can load up the library and pick my functions fine.  However as soon as I close the CLF dialog box I get an error about an undefined parameter.  I think labview is looking for another required library (having to do with the USB interface).  Is there some way I can instruct LabVIEW to look for this library?

Thanks for your help!

 -Yohan

---

For starters you could read this series of articles to see the differences of CINs and the Call Library Node (CLN) and why you would use only CLNs nowadays.

There is no good way to tell LabVIEW how to look for secondary DLLs since not LabVIEW does this but Windows instead. LabVIEW only knows about the primary DLLs you define in the CLNs and tells Windows to load them and then Windows sees that it needs other DLLs and tries to load them. However Windows only knows about specific places it will try to look for DLLs.

1) already loaded in application, use that

2) in the same directory as the executable that started the process

3) in the System directory

4) in the Windows directory

5) in any directory that is named in the PATH environment variable

Looking through this list you can see that you can either make sure your other DLLs are in one of the locations 1) - 4) or change the PATH environment variable to include the directory where your DLLs reside.

Just saw that you are using Linux. There things are in fact a little more complicated. The same applies in terms of the OS doing the loading of secondary DLLs but obviously there is no Windows and System directory.

And the variable that tells the kernel where to look for binary modules is called LDPATH.

Rolf Kalbermatter

Message Edited by rolfk on 10-06-2009 08:25 AM

[YohanShminge]

Alright, thanks for the info Rolf!  I was just starting to read that CLNs were now the better choice.  I had seen some DAQ hardware from Measurement Computing that was using CINs though, so I thought it might be a good place to start.

Thanks,

-Yohan

[Robbob]

Rolf,

That is a very well written series of articles.  I learned much off of them, thanks again for helping the community!