Call library function and setting paths

Hi,
I tried to call a function from a third party dll. I received error that some other dll could not be found. I assumed that the dll that I am accessing is also calling other dll. all these third party dll reside in the same folder in a third party software. I did two things.
1) I place my vi into the same folder as the third party dll and it works. but this is not what I like to do.
2) I duplicate 2 dll which was complained to be missing in the error message. that works too.
it seem like the call library function only search in the folder which my VI resides in and not search in the path which my dll was called.
anyway which I might be able to change this path?
Thanks
Goy

However, this search path only works for DLLs directly accessed by LabVIEW. Any DLLs that are dependent fall back to the Windows search system. For example, if DLL A is called from LV, but A makes a call into DLL B, then the LV path option won't help you find B.
To fix this, you need to add the directory containing B to your system PATH environment variable. Note that you'll need to restart LabVIEW after doing that in order for the LV process to see the change.
The easiest way to do this is to go to Start->Control Panel->System. Select the Advanced tab and then environment variables.
Brian Tyler
http://detritus.blogs.com/lycangeek

Similar Messages

Call library function and path

Hallo,
I want to use a Call library function to use some .dll functions.
Now that call library wants me to give a path to where the dll is stored.
Do I have to put in an absolute path, or can I use some relative path, so
that the call library searches relative to its own position.
That function has no input for path, so it would be hard coded, that's very
unflexible, because the dll would have to be in the same directory structure
on every machine. How can I use a relative path?
Oliver Friedrich

Oliver;
LabVIEW will look first at the path you specified. Then, it will look at the "VI Search Path", which you can see at Tools -> Options -> Paths.
In general, you will not need to write the full path to the dll if you vi is located in the same directory, or if the dll is located in the Windows/System directory or any path indicated in "VI Search Path".
You can also set the path in the "autoexec.bat" file by using the "set path" command.
Regards;
Enrique
www.vartortech.com

Window doesn't close wheh Call Library Function Node set to Run in Any Thread

This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAve

Hi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland

Call library function windows 95

Hi everyone,
I have a problem with the call library function, I have a program that inputs a parameter to the call library function and it all works ok
on a windows 2000 machine but the customer is using windows 95 and LabView 5.0.
When I run the VI on the customers machine (win 95)the output of the call library function is always the same.
Do you guys have any clue why that is happening?
See attached file for the code and more info.
Info on the program:
The dll file connects to an database and checks that the unit under test is at the right station in the production line.
The database connection and everything else works but SFDC_Check always comes back with a zero.
Thanks for the help and taking the time.
Best regards /Johan Lindberg
Best Regards
Johan

Sorry here is the attached file:
Best Regards
Johan
Attachments:
SFDC.zip ‏124 KB

Failed to run parallel path when using call library function node in LV2009

I have a problem with two parallel paths not being run in parallel on LabView 2009.
See the image below.
This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
Is there some limit on parallel threads that is different in 2009 than in other versions ?
Or is there some other problem in 2009 that might cause this problem ?
My labview version is 9.0f3 (32-bit).
Regards,
Rob

I've just installed the DETT tool and checked what the different versions of LabView do.
In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
To answer Ben's question: "What thread does a modal VI run in?":
In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
Thanks,
Rob

Help to make opencv's dll and LabVIEW's Call Library function node understanding each others

Hi, i have a little problem trying to use a C++ opencv's dll in labview. I wrote a really simple and stupid dll just to try to understand how it works the call library function node. Here the header code:
#ifdef GENERICDLL_EXPORTS
#define GENERICDLL_API __declspec(dllexport)
#else
#define GENERICDLL_API __declspec(dllimport)
#endif
#include "stdafx.h"
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <iostream>
#include <string.h>
#include <stdio.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
// Questa classe è esportata da Generic DLL.dll
class GENERICDLL_API CGenericDLL {
public:
int Summ(int a, int b);
int Sott(int a, int b);
int opencv(int a);
// TODO: aggiungere qui i metodi.
and here the .cpp:
// Generic DLL.cpp: definisce le funzioni esportate per l'applicazione DLL.
#include "stdafx.h"
#include "Generic DLL.h"
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <iostream>
#include <string.h>
#include <stdio.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
using namespace cv;
using namespace std;
// Esempio di variabile esportata
GENERICDLL_API int nGenericDLL=0;
// Funzioni esportate.
GENERICDLL_API int Summ(int a, int b)
return a+b;
GENERICDLL_API int Sott(int a, int b)
return a - b;
GENERICDLL_API int opencv(int a)
const string ind = "C:\\Users\\sviluppo\\Desktop\\Tuli.bmp";
const string ind_2 = "C:\\Users\\sviluppo\\Desktop\\Tuli_Gray.bmp";
//Mat image;
return 5;
i can call all the three simple functions in labview with this easy code. No problem at all. If i uncomment the line "Mat image;" the call library function node doesn't work and i receive the error:
"The library specified for this node cannot be found or cannot be loaded. Right-click the Call Library Function node and select Configure, then choose the correct library name or path."
I think that is a problem of dependencies between opencv libraries but i dont know how to manage this. Any ideas?
Thank you for yours time,
Francesco.

Hello Francesco,
I'm having exactly the same problem as you. I created a DLL that I can easily access from LabView. If I add one line and include "imgproc.hpp" (the only one I need), then LV gives me the same error you had. I read the thread Loura linked to, but I don't see how people actually take care of the dependecies (Klemen's examples did not work for me for the same reason, even though I recompiled the .cpp). Could you explain in detail what you did to make it work?
Thanks

Strange problem of calling library function node in labview 2010 and 2011

one year ago,I develop a program to usb device data and it works well,in labview 8.6 or 2009(win xp).Recently, When I test
the program in labview 2010 and labview 2011(win xp).,the program always crash immediately.I check the program and find main
problem is in call library function node. In my program,I use labview 2009 library for the USBExpress driver for
Silicon Labs USB MCU's from:https://decibel.ni.com/content/docs/DOC-9522,for example, 2 functions SI_OPEN and SI_READ
can not work well.
the header definition of SI_OPEN and SI_READ is:
SI_STATUS WINAPI SI_Open(
DWORD dwDevice,
HANDLE* cyHandle
SI_STATUS WINAPI SI_Read(
HANDLE cyHandle,
LPVOID lpBuffer,
DWORD dwBytesToRead,
LPDWORD lpdwBytesReturned,
OVERLAPPED* o = NULL
the SI_STATUS is equivalent to int type.
orignally, for HANDLE * in SI_Open, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass pointer to value.
for HANDLE in SI_Read, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass value.The program works well in labview 8.6&2009,however,crash in labview 2010 &2011.
later,I debug the program, for HANDLE *, I choose parameter type in call library function node as adapt to type, data format is point to Handles.for HANDLE, I choose parameter type in call library function node as adapt to type, data format is Handles by Value.Crash not happend in labview 2010&2011,however,it cannot read any data from from USB device correctly as before.I can not find the reason.
Dear friends,I need your help to answer the problem. Thank you.

Based on the help page it looks like it should execute asynchronously.
The thing in the description that leads me to believe they execute asynchronously is that you can configure the library to run as a multi-threaded operation.
Please take a look here to see the difference between synchronous and asynchronous execution.
Since the code even has the ability to be multi-threaded, you can consider it as running in parallel to your other code.
Any data returned is passed to the thread that called that function.
Cory K

The call library function require us to define the type of parameter that w are using.The type of parameter in cludes numeric, array, string,waveform and adapt to type.I would like to know more about waveform and adapt to type.

In the labview manual, there is very little mention about the use of waveform.How is this waveform being called and can i have an example to see how this work.
Also in the adapt to type paramete, what does this parameter do and in what circumstances do we need to use it.The manual say something about the use of this parametr.It says that scalar elements in arrays or clusters are in line.For example a cluster containing anumeric is passed as pointer to a structure containing a numeric. What does this statement mean?
Can i imply t
hat if my input is a struct, can i use a adapt to type parameter to overcome this incompatibility?Can i also have an example to let me have a better idea.thank you

I'm going to share my experience with the "Adapt to Type" parameter.
Attached to this message is an example. The attachment is a zip file with three files: a dll, a c file and a vi written in LabVIEW 6. The dll contains a function that return a structure with 3 values (like the coordinates of a point in space, that is, (x, y, z)). You can see how the function was constructed by looking at the c file.
In LabVIEW, I created a cluster with the same three parameters. Then, I configured the call library function following the function prototype as in the c file. For the point variable I use "Adapt to Type".
I hope this can give you a head star.
Best regards;
E. Vargas
www.vartortech.com
Attachments:
pointexample.zip ‏63 KB

System Exec and Call Library Function problems

I have working c code. The code connects to a server; makes a request; and gets a return. It works from the command line. In LV there are problems. If I try running it using the System Exec vi, I get the response I expect but not until the connection with the server is broken. This is unacceptible and not the way it works from the command line.
If I try to use the Call Library Function Node, the response is even stranger. I just call the routine that is supposed to connect to the server. It fails.
I attached the vi's. As you will see, they are very simple.
Attachments:
AO call.vi ‏9 KB
AO connect.vi ‏9 KB

exo,
Here is the example Mike was referring to. Let me know if it helps at all.
Brian T
Applications Engineer
Attachments:
Calling System Exec.vi ‏31 KB

Problem with Call Library Function. Want to pass a string and return a string, but my compiler does not recognize "CStr" and Labview does not recognize my "char *function()" callout

Hi, I'm trying to use a .DLL I wrote in Visual C++ .NET. The Call Library Function generates a function prototype of "CStr Parser(CStr arg_raw)"
but my compiler won't accept this. So I change it to how C normally deals with strings "char *Parser(char *arg_raw). Now the Call Librafy Function does not find "Parser" in my .DLL though it is definitely there!
Help!
-Fong

Hello
You will need to include extcode.h in your C file. You can find this under ..\LabVIEW\cintools folder.
The include has all the defines you will need.
Bilal Durrani
NI
Bilal Durrani
NI

Problem in call library function

Hi,
I encountered some problems when using call library function node.
After i select the path in configuration of call library function node, an error message is shown as 1st attachment.
After i tick and the specified path on diagram, link the path name to the node, and run the program. Another error message is shown as 2nd attachment.
Is my dll file got problem? Or i have done a wrong setting?
Here i have attached my dll file.
The dll file is built by Microsoft Visual Studio 2008.
Please kindly advise.
Thank you.
Attachments:
picture1.JPG ‏14 KB
picture2.JPG ‏17 KB
CodeUtil.zip ‏152 KB

TanTan wrote:
Hi,
Is my dll file got problem? Or i have done a wrong setting?
It seems to be compiled for WinCE. Assumed that you have Win2000/XP/Vista/7. Check your MSVC build settings.
Andrey.

PDA: Calling library functions - seems to link the stubbed .cpp file instead of the DLL

I'm having trouble developing a Lab View PDA module that calls a DLL built using Visual C++. The DLL functions correctly when called in a non-PDA VI. My issues seem to be with porting to the PDA.
My configuration:
- Lab View 8.5 with the PDA 8.5 module
- Visual Studio 8.0 with the Windows Mobile 6.0 SDK
- ASUS 626 PDA with an Intel PXA70 procesor running Windows Mobile 6 Classic
Following the PPCBatt example code provided with the PDA module, I have:
- used extern "C" to prevent name mangling
- placed the DLL built with the Windows Mobile SDK in the \Windows directory on the PDA
- created a stub Win32 DLL and lib
- created a stubbed cpp file whose functions only return zero
- included the stubbed cpp and lib files in the build spec / source files / additional files
- placed Call Library Function nodes on my PDA VI, selected the function names, set the parameter types
- built and deployed the executable, both with and without debug
When I set the library path property of the Call Library Node, the functions appeared in the function name pulldown, but the parameters did not populate. I had to manually add them and set their types. The help page says they would autopopulate when the function was selected.
I've debugged the VI, and the Library Function Call nodes are being called. It seems the build is linking the code from the stub C file provided in the additional files portion of the source files property page, instead of adding hooks to call the DLL on the PDA. As a test, I changed an output parameter in one of the functions in the stubbed cpp file - the changed value showed in the front panel indicator.
What am I doing wrong?
Dan

Hi Dan,
I'm not sure if I understood you problem fully. When calling external code with LabVIEW PDA, the DLL acts as a stub DLL with the correct function prototypes for the C code that you want to call. Here's a Knowledge Base article that might help explain about calling External Code in LabVIEW PDA.
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

Call Library Function (DLL) Node Configuration

This issue was discussed few times on this forum (see for example http://forums.ni.com/ni/board/message?board.id=170&message.id=182911 ), but I still have a problem.
My question is - how to define the call to DLL without to specify its full path in order to be able to change the directory path without to change all calls to DLL functions within VI.
So, I did:
1. I put my DLL and my VI in the same directory.
2. I defined this directory in VI search path. This directory also defined as enviroment variable.
3. I use only one call to DLL in this specific VI (just as example in order to simplify the problem).
4. I define only DLL name without the path in CLF Node.
But, every time when I close CLF Node configution window, the program search for the DLL, find it and put full DLL path inside.
I will be very thankful if anyone can help me to overcome this problem.
Best regards,
Boris

Hello Boris,
To sum up the previous posts, when you specify the DLL when configuring the Call Library Function
node, internally LabVIEW stores in the VI either 1) the name of the
DLL, or 2) a relative path from the VI to the DLL (including the name
of the DLL). What's displayed in the dialog (in 'Library Name or Path'
field) is either 1) the name of the DLL, or 2) an absolute path that is
formed by appending the DLL's relative path to the VI's absolute path.
In
case 1, LabVIEW uses the Windows system search paths to load the DLL.
That is, it looks for the DLL in \windows\system32 folder, then if not
found there, it uses the folders specified in the PATH environment
variable, etc.
In case 2, LabVIEW tries to load the DLL from the
computed absolute path (VIs current path combined with the relative
path to the DLL that LabVIEW stored internally). And if not found
there, LabVIEW uses the VI Search Path (that can be set from Tools »
Options in the category of Paths).
So even though LabVIEW automatically puts an absolute path to the DLL
in the Call Library Function Node, as long as you will specify the
correct folder for the DLL in the VI Search Path, you should be Ok. However, if you want to
have a fixed location for the DLL, then it is best to keep it in the
\windows\system32 folder, and specify just the name of the DLL when
configuring the Load Library Function node (this way LabVIEW will not
automatically turn it into an absolute path).
Also, these knowledge base articles might be helpful:
Why Does My VI Prompt for My DLL Every Time I Open It?
LabVIEW Searching for a DLL Used in the Call Library Function Node
My Stand-Alone Executable Cannot Find My DLL, Even Though I Have Specified the Path for the DLL
Hope this helps and good luck with your application!
Shakhina P.
NIC

Call library function not finding DLL in directory where my LLBs are

I am using LabVIEW 8.6. I have a set of VIs in several LLBs. All the LLBs are in one directory. Most of my VIs are wrappers for the functions in one DLL. I was told to put my DLL in the directory where the LLBs are, and supposedly this is how the previous programmer worked (using an earlier version of LabView).
In the Call Library configuration, I have specified <dllname>.dll without a path. (This is how we want it as our VIs are an API which other programmers will integrate, so I don't know where they will put things and I can't use any absolute paths).
When I load the VIs in LabVIEW, LabVIEW can't find the DLL and asks me to located it. It is right there in the directory with the LLBs and when I double click on it everything works fine. However my absolute path to the DLL now appears in the Call library configuration, and we don't want that.
Does anyone know how to make this work? I would assume that the location of the VIs (or LLBs, in this case) would be the current directory and thus Windows would look there for the DLL. However, it seems that this is not the case (at least, in the current version of LabVIEW).
Thank you.
Batya
Solved!
Go to Solution.

rolfk wrote:
Well somebody using your library should not have to dig into your VIs and do all this on his own. Instead your library should wrap that and hide the troubles of this entirely.
That is EXACTLY what I want to do.
The error cluster was added when the dynamic path option was added. It is not useful to hide that error output so it is always there. Together with the dynamic path there was improved error handling added to the CLN. One of them is that the level of error checking during the function call (exception handling) can be specified. I would assume that some of those options can generate an error code instead of popping up a dialog as they did before and for that the error code output can be useful even in the static call case.
As to what you want to do, I would long ago
I would long ago have done a lot of things differently on this project -- but no one asked me then :-) (Good thing it wasn't me, or maybe I'd have taken offense ;-) )
have handled that with a wrapper DLL that has basically the same functions as your other DLLs and some initiliasation function that returns a pointer to a function dispatch structure based on the actual DLL you want to call.
OK, I am getting the feeling that this will be a brilliant and elegant solution when I fully understand it. I understand what a wrapper DLL is. But do you mean that each version of my product would include a different wrapper DLL (with the same name so that CLN would always work), or the same one and it would somehow be told which actual DLL I want to call? Who would decide which DLL, the VI or the wrapper DLL?
By a function dispatch structure do you mean a table of function pointers gotten by GetProcAddress, one such entry for each function?
Quite like what an object oriented function dispatch table is. Then when initilising your interface you call that initialise function and specify the interface/device type you want to use and after that all the other functions take one additional function dispatch pointer parameter as first parameter in addition to the parameters the actual function has. This function dispatch pointer would be just a pointer to a structure containing the table of function pointers for that interface and for the sake of LabVIEW would be simply a pointer sized integer.
The wrapper function then verifies the function dispatch structure pointer for validity and calls the actual function with the remaining parameters.
I think I understand what the wrapper functions need to do. But I am missing some pieces for the initialize function. It would have to do LoadLibrary and lots of GetProcAddresses -- that much I get. But I still don't understand who decides which DLL. Maybe you mean that the wrapper DLL's initialize function will get the DLL name and path from the registry, load it, try a different path if the load fails, etc. Is that what you mean? That could work very nicely. But from where would it get the registry key? From the VI? This is the part that would clearly be different for each product. I suppose that you had something in mind when you described your solution.
This is some C programming
Great! That's what I do for a living. At least I know how to do that! Hey, I should have thought of this idea!
and might require some planning and desigining of the different interfaces to facilitate this kind of dispatch technique but it will for sure pay of in the long run, and make your library even usable in earlier LabVIEW versions, as well as VB etc. without tricky dynamic loading in the high level programming environment.
Ah, see how much I don't know in LabVIEW? I didn't know this was a new feature...
Thank you for the great idea.
Batya Perlman

Call library function node: function not found in library

I'm using Labview 6.1 and Windows XP. I am trying to open some code, but it opens up with a broken arrow. The error is Call Library Function Node:function not found in library. Tried to configure the node, but no change. Moved the DLLs to various directories (keeping them together) but again no change.
This code has been compiled and is working fine. I'm just trying to run the source code to make some modifications. Any suggestions?
Thanks
CarlosV

Thanks for the suggestions. Tried it but had the same results. The library I'm using is hpe1413_32.dll.
One thing I forgot to mention....doing a configure on the node, it comes up with the library: hpvscp32.dll and the function: hpe1413_error_message
The function doesn't exist in the library. So I set the path to hpe1413_32.dll which does contain the function.
After closing the configuration window and opening it up again, the library shown is hpvscp32.dll
From what I can tell, there are three libraries involved:hpe1413_32.dll, hpe141332v.dll, and hpvscp32.dll
Thanks again.
Carlos

Call library function and setting paths

Similar Messages

Maybe you are looking for