"Call Library Function" absent from performance profiling

Hello,
I'm trying to optimize my VI execution time by using the "Profile Performance and Memory" window.
The VI takes 25 sec to run, however the profiler reports something like 25 ms, if I understand correctly.
I know the 25 sec includes all other processes on the CPU. However I highly suspect a lot of time is spent in 3rd party DLL functions I use, which read and write files, among other things.
The problem is that the "Call Library Function" nodes do not appear in the profiler window at all! My questions:
1) Why don't clf nodes appear?
2) Is there some way to inspect the time spent in the DLL functions?
Note: There is a related (unanswered) post from 2009 here: http://forums.ni.com/t5/LabVIEW/Profile-performance-of-a-VI-using-DLL/m-p/888833#M401525
Thanks
Itay.

I recommend taking the simple approach - put a millisecond timer function before and after the call to the DLL, and subtract. I suspect that CLFNs do not appear in the profiler because LabVIEW hands off execution to the DLL and can't monitor the internals of what the DLL is doing. LabVIEW has no way to know how much memory the DLL allocates nor how much processor time the DLL uses.

Similar Messages

Call multiple functions from same dll with call library function

hi,
i am working on a project in wich we need to make a UI to read out a sensor network.
the UI should be usable in any project, but every node needs a different piece of code depending on the type of sensor with wich it is equipt.
so i need to be able to call different pieces of code when i need them, and still be able to use the UI in future projects with possibly new types of node we now don't have.
so someone told me to use DLL's, cause then i would be able to call the code i need the moment i need it.
but i have never worked with DLL's (just learned about this option 3 day's ago) so i have a question.
i know i can dynamicly change the DLL i call with the call library function, but can i dynamicly change the function i call from that DLL ?
or do i have to put a new call library function for each function i want to call, even if its from the same DLL ?
kind regards,
stijn

nazarim wrote:
ok so there is no (easy and ubderstandable) way for me to dynamicly change wich function i want to call from a certain DLL.
but now i started wondering, the path on the call library function is not ment to dynamicly change a DLL
but it does work so, if i am carefull, can i use it for that purpose or will labview give me a series of problems once i start using it in larger programs ?
Thepath on the Call Library Node can be used to load a different DLL. Obviously since you can't change the function name your other DLL would have to export exactly the same function name and of course with the same parameters. This is seldom the case so it is not the main use of the path input to the Call Library Node. It's main use is as indicated to load DLLs at runtime rather than at load time of a VI. So that an application can run even when the DLL is missing, until the moment the functionality from that DLL is needed.
If you can make sure that all your DLLs export the same function name with the same parameter you can use the Call Library Node to call into different DLLs through the path input. If however you would need to call different function names you would have to resolve to some DLL which does do the dispatching and invocation using LoadLibrary() and GetProcAddress(). But unless you need to go with DLLs for some reason using the Call By Reference Node can give you an even more flexible approach.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to call a C pointer from call library function node

I have a client/server application which the client I am trying to develop using Labview. When I use to communicate the server and the client using the program provided by the manufacter, the system works perfectly.
Now, I am trying to develop a system using labview, because I need to get another things.
I have the DLL provided by the manufacter and the .h too, so I can check the functions parameters. One of these functions needs to be called using a struct element. Probably, the function's DLL instantiates the elements of this struct. I use the call library function node to do it.
When I receive the data, the function returns to me the struct that I passed as a parameter before, and then I can read all the elements of the struct, except the string element that returns nothing. The struct elements that are numerical, I can read them perfectly.
Another thing that is important to say, is that the string data was not returned in fact by the DLL function that the system calls. I have to pass a pointer (I use it as unsigned 16 in Labview, but I tried before as string and unsigned 8) as a parameter, and this pointer will point to the memory location that the string is. When I try to read what is returned by the function, I can read nothing. The same function returns that the size of data that is returning is 17 bytes.
How can I solve it?
Thank you in advance

Did you take a look at the example that ships with LabVIEW that shows how to do all sorts of data passing to DLLs. I believe your situation is one of the examples listed. You can find the example VI in the "<LabVIEW install directory>\examples\dll\data passing" directory.

Passing arrays with Call Library Function does not work after application builder

Calling a DLL with Call Library Function which requires an array of data works correctly in Labview, but after building an exe with application builder, the call no longer works. Dereferecing the pointer in the DLL retuns all 0s and not the actual values.
Solved!
Go to Solution.
Attachments:
TEST.zip ‏28 KB

I did not run your code because it is a little unclear to me what it does.
Two things:
First, is the DLL you are calling the DLL-ified version of PopUpNames.vi? Then the problem is likely that the panel is not being built into the DLL.
When LabView builds an application / dll, it strips the front panel and block diagram from all VIs that it doesn't think need to show a panel at run time. This reduces file size and increases code security. The App Builder's panel inclusion logic can be overridden by Build Specifications -> Source File Settings -> Remove front panel. A better method is to put a property node on a control in a window you want to show marking it "visible"; this is sufficient to tell the App Builder it should keep the panel.
Currently Source File Settings shows "no dependencies" (clearly incorrect---another evil side effect of Express VIs I guess) but if you change the settings as shown below to keep ALL panels, one might hope the App Builder can figure it to keep the panel when it deconstructs the Express VI. (Alternatively convert the Express VI into a regular one.)
A second comment: I am a bit flummoxed at the larger goal here. You are calling LabView DLL from LabView, which doesn't make a lot of sense, so I assume your larger goal is to call LabView from C or vice-versa. In that case be aware that your DLL is x86 (32-bit) but you are passing 64-bit ints as your pointers. In this case it is 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers calling 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers, so it all works, but if your going to call this from C or whatnot you're going to have to follow that same design.
When calling C code the LabView Call Library Function does have a "unsigned pointer-sized integer" data type that always appears to be 64 bits in the dev env but which actually passes a 64 or 32-bit int to the DLL depending on the environment. The "pointer sized int" has to be 64 bits in the "LabView" part of the code because LabView's strong typing requires the data type to be determined at compile time. Casting all pointers to the largest data type in LabView makes it possible to write platform-independent code, but down at the Call Library level you still have to put the right number of bytes on the stack.

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

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 node with array of clusters using array data pointer

Hello all.
I am writing a LabVIEW wrapper for an existing DLL function.
The function has, as one of its parameters, an array of structs. The struct is very simple, containing two integers. I am using the call library function node to access it.
In Labview I created an array of clusters, where the cluster has two 32-bit integers as its members. So far, so good.
Now I have to pass this in to the Call Library Function Node. Here I am running into trouble.
I have used The topic in LAVA and The topic in the knowledge base as my primary sources of information, though I have read a bunch of forum topics on the subject too.
I do understand that I could write a new function which takes as a parameter a struct with the size as the first member and an array as the second, and I might just do this and have it call the regular function, but I was hoping to do it more simply.
According to the C file which LabVIEW generates for me from the CLFN when I choose "Adapt to Type" and "Array Data Pointer", the prototype it is expecting is:
int32_t myFunc(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
And the prototype of the function in my DLL is
int borland_dll myFunc(DWORD handle, usint channel,
int FIFOnumber, struct mStruct *data, int numWords, int *actualLoaded, int *actualStartIndex);
This looks like a match to me, but it doesn't work (I get garbage in data). From the topic in LAVA referenced above, I understood that it would work. It does not.
If I cast data to the pointer-to-pointer I get when I generate c code by wiring my struct to a CIN and generating, then I seem to get what I expect. But this seems to work when I choose "pointers to handles" too, and I would expect array data pointer to give a different result.
Is there any way to get this to work directly, or will I have to create a wrapper? (I am currently using LabVIEW 2011, but we have customers using 2009 and 2012, if not other versions as well).
Thank you.
Batya
Solved!
Go to Solution.

OK, here is more detailed information.
I have attached the VI.
This is the code from the "C" file created by right-clicking the CLN and creating a "C" file.
When the parameter in the CLN is set to "array data pointer":
/* Call Library source file */
#include "extcode.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is "pointers to handles":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is set to "handles by value":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
As to the DLL function, it is a bit more complicated than I explained above, in the current case. My VI calls the function by this name in one DLL, and that DLL loads a DLL and calls a function (with the same name) in the second DLL, which does the work. (Thanks Rolfk, for helping me with that one some time back!)
Here is the code in the first ("dispatcher") DLL:
int borland_dll Load_Transmit_FIFO_RTx(DWORD handle, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex)
t_DispatchTable *pDispatchTable = (t_DispatchTable *) handle;
int retStat = 0;
retStat = mCheckDispatchTable(pDispatchTable);
if (retStat < 0)
return retStat;
if (pDispatchTable->pLoad_Transmit_FIFO_RTx == NULL)
return edispatchercantfindfunction;
return pDispatchTable->pLoad_Transmit_FIFO_RTx(pDispatchTable->handlertx, channel, FIFOnumber, data, numWords, actualLoaded, actualStartIndex);
borland_dll is just "__declspec(dllexport)"
The current code in the DLL that does the work is:
// TEMP
typedef struct {
int control;
int data;
} TD2;
typedef struct {
int dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
// END TEMP
int borland_dll Load_Transmit_FIFO_RTx(int handlertx, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex){
struct TRANSMIT_FIFO *ptxFIFO; //pointer to transmit FIFO structure
usint *pFIFOlist; //pointer to array of FIFO pointers to FIFO structures
int FIFOentry, numLoaded;
usint *lclData;
usint nextEntryToTransmit;
// TEMP
FILE *pFile;
int i;
TD1** ppTD = (TD1**) data;
TD1 *pTD = *ppTD;
pFile = fopen("LoadFIFOLog.txt", "w");
fprintf(pFile, "Starting Load FIFO with %d data words, data pointer 0x%x, with the following data&colon; \n", numWords, data);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, data[i].control, data[i].data);
fflush(pFile);
fprintf(pFile, "OK, using CIN generated structures: dimSize %d, with the following data&colon; \n", pTD->dimSize);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, pTD->data[i].control, pTD->data[i].data);
fflush(pFile);
// END TEMP
if ((handlertx) <0 || (handlertx >= NUMCARDS)) return ebadhandle;
if (cardrtx[handlertx].allocated != 1) return ebadhandle;
pFIFOlist = (usint *) (cardrtx[handlertx].segaddr + cardrtx[handlertx].glob->dpchn[channel].tr_stk_ptr);
pFIFOlist += FIFOnumber;
ptxFIFO = (struct TRANSMIT_FIFO *)(cardrtx[handlertx].segaddr + *pFIFOlist);
//use local copy of ptxFIFO->nextEntryToTransmit to simplify algorithm
nextEntryToTransmit = ptxFIFO->nextEntryToTransmit;
//on entering this routine nextEntryToLoad is set to the entry following the last entry loaded
//this is what we need to load now unless it's at the end of the FIFO in which case we need to wrap around
if ( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries)
*actualStartIndex = 0;
else
*actualStartIndex = ptxFIFO->nextEntryToLoad;
//if nextEntryToLoad points to the last entry in the FIFO and nextEntryToTransmit points to the first, the FIFO is full
//also if nextEntryToLoad == nextEntryToTransmit the FIFO is full and we exit without loading anything
if (( (( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
( ptxFIFO->nextEntryToLoad == nextEntryToTransmit)) && (ptxFIFO->nextEntryToLoad != INITIAL_ENTRY)){
*actualLoaded = 0; //FIFO is full already, we can't add anything
return 0; //this is not a failure, we just have nothing to do, this is indicated in actualLoaded
numLoaded = 0;
lclData = (usint *)data; //must use 16 bit writes to the module
//conditions are dealt with inside the for loop rather than in the for statement itself
for (FIFOentry = *actualStartIndex; ; FIFOentry++) {
//if we reached the end of the FIFO
//if the module is about to transmit the first element of the FIFO, the FIFO is full and we're done
//OR if the module is about to transmit the element we're about to fill in, we're done - the
//exception is if this is the first element we're filling in which means the FIFO is empty
if ((( FIFOentry >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
((FIFOentry == nextEntryToTransmit) && (FIFOentry != *actualStartIndex) )){
*actualLoaded = numLoaded;
//set nextEntryToLoad to the end of the FIFO, we'll set it to the beginning next time
//this allows us to distinguish between full and empty: nextEntryToLoad == nextEntryToTransmit means empty
ptxFIFO->nextEntryToLoad = FIFOentry;
return 0;
//we reached the end but can continue loading from the top of the FIFO
if ( FIFOentry >= ptxFIFO->numEntries)
FIFOentry = 0;
//load the control word
ptxFIFO->FifoData[FIFOentry * 3] = *lclData++;
//skip the high of the control word, the module only has a 16 bit field for control
lclData++;
//now put in the data
ptxFIFO->FifoData[(FIFOentry * 3) + 2] = *lclData++;
ptxFIFO->FifoData[(FIFOentry * 3) + 1] = *lclData++;
numLoaded++;
//we're done because we loaded everything the user asked for
if (numLoaded >= numWords) {
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry+1;
return 0;
//if we reached here, we're done because the FIFO is full
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry;
fclose (pFile);
return 0;
As you can see, I added a temporary diagnostic with the structures that were created in the "Handles by value" case, and print out the data. I see what is expected, whichever of the options I pick in the CLN!
I understood (from the information in the two links I mentioned in my original post, and from the name of the option itself) that "array data pointer" should pass the array of data itself, without the dimSize field. But that does not seem to be what is happening.
Batya
Attachments:
ExcM4k Load Transmit FIFO.vi ‏15 KB

How to implement a callback function using LabView's Call Library Function Node?

I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
The SDK.h deacribes the function as:
// Function:   SdkSetPropertyEventHandler
SdkError SDKAPI SdkSetPropertyEventHandler(
            SdkCameraRef                    inCameraRef,
            SdkPropertyEvent                inEvnet,
            SdkPropertyEventHandler         inPropertyEventHandler,
            SdkVoid*                        inContext );
// Description:
//       Registers a callback function for receiving status
//          change notification events for property states on a camera.
// Parameters:
//       In:    inCameraRef - Designate the camera object.
//              inEvent - Designate one or all events to be supplemented.
//              inPropertyEventHandler - Designate the pointer to the callback
//                      function for receiving property-related camera events.
//              inContext - Designate application information to be passed by
//                      means of the callback function. Any data needed for
//                      your application can be passed.
//      Out:    None
// Returns:    Any of the sdk errors.
A separate header file called SDKTypes.h contains the following data:
typedef SdkUInt32 SdkPropertyEvent;
typedef SdkUInt32 SdkPropertyID;
typedef void       SdkVoid;
typedef struct __SdkObject*    SdkBaseRef;
typedef SdkBaseRef    SdkCameraRef;
SdkPropertyEventHandler
typedef SdkError ( SDKCALLBACK *SdkPropertyEventHandler )(
                    SdkPropertyEvent        inEvent,
                    SdkPropertyID           inPropertyID,
                    SdkUInt32               inParam,
                    SdkVoid *               inContext );
Thanks for your help.
Alejandro
Solved!
Go to Solution.

alejandroandreatta wrote:
I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
Basically you do not do that. LabVIEW does not know pointers and certainly not function pointers. What you should do instead is writing a C DLL that implements the callback and also exports a function to be called by LabVIEW that translates between the callback and a LabVIEW user event. Look for PostLVUserEvent() here on the NI site to find examples how to do that.
Rolf Kalbermatter
Message Edited by rolfk on 02-11-2009 08:00 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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

Execution time for Call Library Function Node

I am experimenting with the Call Library Function Node block in LabVIEW and am curious if it should be running faster than what I'm seeing. For testing purposes, I have compiled and transfered to my RT target the .out file from the KB article http://digital.ni.com/public.nsf/allkb/81D1172E3C28A5E4862575CC0076A230 (I'm using the vxworks 6.1 version). The function in the .out file just multiplies two inputs together, adds a constant, and returns the result. I have put this inside a 1 kHz timed loop with a commanded period of 1 ms and via the Ticks(ms) block and shift registers I calculate the amount of time per loop execution. This process is apparently taking 5 ms per cycle and to me that seems slow. Is that roughly the correct execution time for this kind of setup? I will attach my test .vi file.
What I'm using:
Windows 7
LabVIEW 2009 SP1
NI-cRIO 9024 with NI-RIO 3.4.0
Solved!
Go to Solution.
Attachments:
test DLL.vi ‏31 KB

First off, the way you are doing timing isn't necessarily accurate because you don't know when the tick count VI is being called. For example, if it gets called on one iteration after your call library node executes, and the next iteration it gets called before the CLFN it executes, the subtraction doesn't include the call of the CLFN so you aren't seeing the true time it is taking for the dll to be called.
Where it says "error" on the top left hand corner of your loop. left click and choose previous iteration timing. Also, do you have the ability to choose a 1 Mhz clock? Are you sure it's actually being run on the RT and not on your PC? Running it on the PC would definitely make it difficult to execute at a 1 kHz rate.
CLA, LabVIEW Versions 2010-2013

Call library function inside a conditional disable bug

i'm trying to call a function in a dll using the call library function inside a conditional disable structure.
one of the parameters is a pointer to a C structure.
here is the prototype:
short in myfunction(short in DevNum, void *pMetrics);
outside of the conditional disable, LabVIEW allows me to wire the pMetrics parameter to a cluster.
if i put the function inside the conditional disable, LabVIEW doesn't allow me to wire it.
as a workaround, i put the cluster inside the conditional disable as well.
any ideas?

Simply create a constant of the cluster and and put it outside the disable structure. Wire this constant to all inputs (left side terminal) of the Call Library Node. A Call Library Node (CLN) set to Adapt to Type does need a valid datatype to adapt too. This works from the outside side (right side terminal) of the CLN only if the according indicator is inside the same data structure. In older LabVIEW versions you actually had to always define the left side by wiring a constant or a dummy control to it.
This has to do with the algorithme that evaluates datatypes along wires. Making that algorithme go backwards (against the natural dataflow) inside one subdiagram without causing circular references or similar is already a challange. Doing that across diagram boundaries (case, disable, loop, etc. structures) is basically impossible without causing the entire edit operation to get very slow.
Message Edited by rolfk on 10-20-2009 08:28 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Call library function will not retain change of directory for the library.

I have created a call to a dll made in Visual C++. Everything works fine. I then configure the vi to call the a newer version of the library that is in another directory. The Call Library Function dialog box updates with the new path. I click the OK button. Then configure the vi again to very my change took and it is back to the original path to the library.
Why can I not change where to find the library? I am sure that I can make a new vi an input all the parameters again, but I have many parameters and calls to the same dll. Making new ones each time the location of the dll changes is not an option.
Thanks for your help.
Attachments:
code.zip ‏106 KB

If you have more than one VI accessing the same DLL, then you can't
change the DLL location without unloading all the other VIs first. This
is because Windows will always look first for the DLL in memory, before
even attempting to load it from disk. And if another VI makes use of
that DLL it will be still kept in memory.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Call Library Function with C structure

I have been given a MS C++ DLL that I need to call from LabVIEW. The input (and output) to the DLL are pointers to "C" data structures.
The LabVIEW "Call Library Function" VI allows you to add input parameters and define their type (I.e. Numeric, Array, String, etc.) However, "C data structure" is not one of the options. Is there a way in LabVIEW to call/use a MS C++ DLL that requires a data structure as an input and returns a data structure as the output?

It is possible to pass structures to called DLLs in LabVIEW. Typically the structure will be passed through the means of a cluster. Please see the link below for more information on calling external code in LabVIEW.
Using External Code in LabVIEW
You can also find a great example VI on calling DLLs in the LabVIEW example finder. Search for the keyword DLL and open up Call DLL.vi. This example shows most of the common ways to pass data between LabVIEW and external code.
Regards,
Matt F
Keep up to date on the latest PXI news at twitter.com/pxi

DIO Port Config & DIO Port Write Block Diagram Errors (Call Library Function Node:library not found or failed to load)

Hi Guys, need help on this.
I have this LabVIEW program that used to work on the old computer.
The old computer crashes most of the time, so I upgraded the computer
and used its Hard Drive as slave to the new computer.
I have no idea where are its installers since the guy that made the program
is not in my department anymore.
I downloaded all the drivers needed from NI: NIDAQ9.0, NIVISA,NI488.2,
and drivers of some instruments needed in the setup. I'm using LabVIEW8.2.
Everything's fine until I open the LabVIEW program for our testing.
Here goes the error:
   DIO Port Config
   DIO Port Write
Block Diagram Errors
   Call Library Function Node: library not found or failed to load
Attachments:
ErrorList.JPG ‏200 KB

Honestly, I'm a newbie on Labview. I just want this old program to run on the new computer.
The guys that installed the drivers on the old computer are no longer here in my department.
And I have no idea where the drivers are. So I just downloaded the drivers needed for my hardware and instruments.
Here's my hardware: (cards: PCI-DIO-96, PCI-GPIB), (instruments: SCB100,E4407B, HP83623, HP3458, HP8657)
OS: Windows XP Pro
By the way, I have unzipped the TraditionalDAQ drivers. First I tried the 7.4.1, but installation error appeared.
I thought maybe the installer is corrupted, so I downloaded the 7.4.4 and unzipped it.
But, still same installation error appears. I don't understand, both TraditionalDAQ drivers have same installation error.
Now I have tried the DAQmx8.7.2 driver, bu still the DIO Port Config and DIO Port Write have errors.

"Call Library Function" absent from performance profiling

Similar Messages

Maybe you are looking for