Nested library function call

Is it possible to create a DLL using the LabVIEW Application Builder from a VI that already contains a library function call?
Thanks,
mlloyd

Hi mlloyd,
This should definitely possible. If you dig deep enough, you'll realize that some of our VIs such as DAQmx, signal analysis, etc, use Call Library Function Nodes, and you can build those into a dll, so this should work.
Best regards,
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

Similar Messages

Advantages of Solaris 10 library function calls over Solaris 8 calls.

Hi,
We are planning for a migration of OS from Solaris 8 to Solaris 10. We referred some documents related to Solaris 10 features and the 'What's new' document for Solaris 10. However we couldn't find much difference on library function calls.
It would be really grateful if anybody could give some more information on the function calls that are changed from Solaris 8.
Thanks,
Palani_techm.

Can you be more specific? There's are whole slew of changes (dtrace, driver framework changes (usb, gldv3, sata...), graphical changes (gnome, opengl) ), some function additions to make linux source compatibility easier. I don't think the C library (3C) has been changed that much minus new functions, since it would make forward compatibility more difficult.

C library function call - Unavailable Type for one of the parameters in the Function Prototype.

Hi,
I'm doing a job that has been already done by some others: implementing a LabVIEW SQLite Wrapper, I know how to do that with .NET alas I would like to do that in C, mostly for performance purposes and my poor pointer knowledge is kinda make me stuck.
A couple of informations are kindly provided here:
http://www.sqlite.org
http://www.sqlite.org/cintro.html
What I would like to do, is just to open a connection to a SQLite Database (if not existing, the SQLite engine will create the embedded Database and the related file to save the data and everything). The function to perform the operation is given in page below:
http://www.sqlite.org/c3ref/open.html
It seems pretty simple:
int sqlite3_open(
const char *filename, /* Database filename (UTF-8) */
sqlite3 **ppDb /* OUT: SQLite db handle */
int sqlite3_open16(
const void *filename, /* Database filename (UTF-16) */
sqlite3 **ppDb /* OUT: SQLite db handle */
int sqlite3_open_v2(
const char *filename, /* Database filename (UTF-8) */
sqlite3 **ppDb, /* OUT: SQLite db handle */
int flags, /* Flags */
const char *zVfs /* Name of VFS module to use */
However I'm struggling a bit about the following type:
sqlite3 **ppDb /* OUT: SQLite db handle */
And I'm not really sure about which type to use when I'm calling this function from LabVIEW
Any idea, I guess it's real easy, but I'm not really used to have a type which is I suppose the DataInstance but as it's not clearly explicted in the LabVIEW interpreted C Library Function prototype (InstanceDataType makes sense but not sure though) I'm not really sure what I'm showing in the attached screenshot is valid or not.
My VI seems to work like a charm, but don't really know if I'm doing something wrong.
Another prototype that I have no idea about the proper LabVIEW call is the close function:
http://www.sqlite.org/c3ref/close.html
Let me get this traight, usually a parameter has a name, right? but seems that nope:
int sqlite3_close(sqlite3*);
int sqlite3_close_v2(sqlite3*);
So also no idea about the parameter setting for this one... has to be considered as the self instance like the one calling this function is this... but I'm not passing any object?
Really confusing...
sqlite3*
I might sound really silly, but if anybody could point me some directions, I would be really grateful for that.
Thanks

Ehouarn wrote:
However I'm struggling a bit about the following type:
sqlite3 **ppDb /* OUT: SQLite db handle */
And I'm not really sure about which type to use when I'm calling this function from LabVIEW
This parameter should be a pointer-sized integer, passed by pointer. Doesn't matter if it's signed or unsigned. The SQLite library will allocate memory for you, then put a pointer to that memory location into the pointer-sized integer that you pass in.
As for the close function, you should pass that same pointer-sized integer, but this time pass it by value (because it's referenced with a single *, not two). There's nothing wrong with the documentation omitting the parameter name. For the purposes of a function prototype, the parameter name is unimportant, since all you need to know is the type of the data. How the function chooses to refer to that parameter internally is irrelevant.

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

Hi,
I just transfered some of my programs (in LV5.0 - student edition) from one computer to another. The programs work perfectly on computer A, but when I transfered them to computer B, an error comes up saying 'call library function not supported in this version'. What I don't understand is that I am using the exact same LV5.0 student edition on both computers - was maybe an update installed on the original computer to allow the call library function to work? If so, where could I find this? Any other ideas why I can't use Call Library Function on computer B?

Hi LV newbie,
Th call library function calls functions within a dll. The dll can be an API or driver from the equipment manufacturer or custom-made functions to control or communicate with the DUT.
So the first thing I would look for is the dll in question.
When you transferred the LV code from computer A to B, did you do a mass compile? (Tools > Advanced > Mass Compile). You can try that. If already done that, open the vi giving you trouble and look at the call library function. Is it pointing to the right directory to find the dll? The problem may be in the ability for the vi to find the dll. Make sure it is calling the right function(s) and passing the appropriate parameters and values. Strange things can happen when moving LV from one PC to
another.
Let us know your progress.
JLV

Debug gives non-exect.,Call Library Function: no library specified error?

I have installed the VISA 2.6 as mentioned in order to be able to see the VIs for my TDS5104 scope. The VIs are still not exectuable because of this library function call. I have followed all instructions pertaining to the labview add on, etc. I have the tektronix drivers installed. How do I fix this error so that I can actually program my specific solution?

Hi,
I looked for the instruments driver at www.ni.com/idnet and found NI Instrument Drivers Network: TDS 5054 Multi-Environment Plug and Play Instrument Driver for the instrument. This driver is developed by Tektronix.
I don't have the driver available, but it is most likely that the Library node VIs can not find the dll. Go to the VIs that are not executable, right click on the library call node and select configure. Note the path and the name of the dll the node is configured to use. You can then look for the dll in your system. You have 2 options: change the path in the node to point at the location of the dll or copy the dll to the location the node is expecting to find it. Any of
those should make the node executable.
Hope this helps.
DiegoF
National InstrumentsMessage Edited by Molly K on 02-18-2005 11:02 PM

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

How can I debug the Call Library Function at run-time

I've written a VI using the CLF to call a DLL which was compiled off-site by another engineer using MSVC. Even though the VI runs without flagging any errors, the VI is not doing what I expect. Is there any way of finding out if the DLL is been called correctly? The first function that is called doesn't return any value, but I think that it should. Does this mean that the DLL is not being called correctly? Note also that the DLL works fine with a JAVA GUI.

Make sure that you are specifying the proper function prototype in the call library function. If you are slightly off the call will not work properly. Ask the offsite engineer to provide you with this data. Another tip is to build the dll with the option to show front panel when called. You can actually popup the dll like you would a subvi. If you design it with test indicators showing on the front panel that is a great way to determine if it is working. Hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

When i open my i3tunes on my computer i get an error message telling me that iTunes has stopped working..the message is as follows...Microsoft Visual C runtime library Program C:\program files (86) iTunes\iTunes.exe R6025 -Pure virtual function call..

when i open my i3tunes on my computer i get an error message telling me that iTunes has stopped working..the message is as follows...Microsoft Visual C runtime library Program C:\program files (86) iTunes\iTunes.exe R6025 -Pure virtual function call.. How do i fix this

For general advice see Troubleshooting issues with iTunes for Windows updates.
The steps in the second box are a guide to removing everything related to iTunes and then rebuilding it which is often a good starting point unless the symptoms indicate a more specific approach. Review the other boxes and the list of support documents further down page in case one of them applies.
Your library should be unaffected by these steps but there is backup and recovery advice elsewhere in the user tip.
tt2

ITunes crashes when doing a power search. I get a Microsoft Visual C Runtime Library Error message: Program C:\Program Files (x86)\iTunes\iTunes.exe R6025. Pure virtual functional call. If I select ok, Windows 7 pops up with iTunes has stopped working

iTunes crashes when doing a power search. I get a Microsoft Visual C Runtime Library Error message: Program C:\Program Files (x86)\iTunes\iTunes.exe R6025. Pure virtual functional call. If I select ok, Windows 7 pops up with iTunes has stopped working and then it shuts iTunes down. Anyone else every have this issue. Any ideas on a fix?
Thanks,

For general advice see Troubleshooting issues with iTunes for Windows updates.
The steps in the second box are a guide to removing everything related to iTunes and then rebuilding it which is often a good starting point unless the symptoms indicate a more specific approach. Review the other boxes and the list of support documents further down page in case one of them applies.
Your library should be unaffected by these steps but there is backup and recovery advice elsewhere in the user tip.
tt2

Using call library function on a dll file created in an old version of labview

So I'm trying to update an old labview program to work in labview 2012. Everything converted over just fine but labview will always crashoverwrote some while using a library function in a DLL that was compiled using labview 8.5. Labview exits, stating that it vital memory area. It passes an array of data to the library call and an empty array for output. I thought I could get around this problem by changing my code to initialize the array being passed in so that it would be large enough to hold all the expected output. Now instead of overwritting areas of memory it shouldn't, I get a pop up message that says:
fatal internal error
memorymanager.cpp line 406
8.5.1.f5
So it appears because I don't have the ability to recompile the DLL file it runs off of the 8.5 runtime instead of the more recent one. Is there any thing I can do about this?

rjpierce wrote:
So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with.
Your problem most likely is that you try to pass native datatypes to the DLL function? That only can work if the caller and callee use the same LabVIEW runtime engine. Otherwise the memory block created in the memory manager of the caller will be accessed by the memory manager in the callee and bad things happen. Instead you should define the DLL function to use standard C datatypes (Pointer to C array) and also make sure to allocate the according buffer in the caller for all output array parameters.
An even more elegant way would be to completely abandon the DLL approach and call the according functions directly in LabVIEW. Then you won't have the problems about mismatched runtime engines. Passing C array pointers to a DLL is less performant than passing native datatypes, but if you use native datatypes you have to make sure the DLL is compiled in the same LabVIEW version as the one you call it from.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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.

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

Nested library function call

Similar Messages

Maybe you are looking for