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

Similar Messages

Call library function node - function not found

When creating a DLL I get a the Labview error "Call Library Function Node "LabviewReceiverDLL.dll:readDataJ1939Data' Function not found. Everything looks correct to me and this used to work, though I've changed computers since then.
This is the beginning of my C++ code just to show my function name. I've also attached the Call Library Function Window to show my setup.
Thank you in advance for your help.
#include"StdAfx.h"
#include<iostream>
/* Call Library source file */
extern"C"__declspec(dllexport)unsignedint readDataJ1939Data(unsignedint, unsignedint, unsignedchar, unsignedchar* canData, unsignedchar* path);
unsigned int readDataJ1939Data(unsignedint ulTimeStamp, unsignedint ulIdentifier, unsignedchar uiDataCount, unsigned char* canData, constchar* path)
Solved!
Go to Solution.
Attachments:
Call Library Function.png ‏192 KB

You mention that you have changed computers and that it used to work before.
Could it be that there is another (older) copy of the DLL on this computer, and LabVIEW is loading the wrong one?
The simplest way to check is to close your VI and delete the one you are expecting it to use. Then open the VI again; if LabVIEW doesn't ask you where the DLL is, it is loading it from somewhere else.
Batya

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 Node 'Wrapper.Create': Library not found or failed to load. using windows 7 64 bits

Dear all
I try to interface my spectrometer (NIRquest from ocean optics) using labview on my 64 bits cumputer using windows 7.
I have absolutely no problem to run the spectrometer with the program dedicated to the spectrometer (called Spetrasuite).
I've installed "OmniDriverSPAM-1.66-win64-development-installer.exe" and everything went right.
When I select a VI in LabView (e.g."wrapper_create.vi") from the wrapper.llb, LabView returns an error :
"Call Library Function Node 'Wrapper.Create': Library not found or failed to load."
I chek the call library function, but everyting seems to be right :
I use LabView 8.6.1 and my others *.vi are running perfectly...
Do you have any idea from where does the problem comes ?
Thank you very much

Hello Flanguy,
In addition to smercurio_fc's feedback I can confirm that LabVIEW 8.6.1 doesn't exist in 64-bit version.
Officially, LabVIEW 8.6.1 doesn't support Windows 7 either.
The minimal version of LabVIEW you would need to both support Windows 7 and exist in 64-bit version is LabVIEW 2009 64-bit or any 64-bit versions which are more recent.
In the two links (1 & 2) you can find more background information.
Kind Regards,
Wouter
National Instruments Belgium

Call Library Function Node produces error in Windows 7

Hi,
I've created a simple program using LabVIEW 8.5 that uses calls in winscard.dll to read and write to a Smart Card. I use Call Library Function Node to call functions in C:\Windows\System32\winscard.dll. This program works without a problem in Windows XP both within LabVIEW 8.5 and once it is compiled. I am also able to get this program to run without a problem when I run it in LabVIEW 2011 on a Windows 7 machine. However, when I run the program compiled with LabVIEW 8.5 on Windows 7, the first call I make to a function in the DLL returns Windows System Error 2 (file not found). Subsequent calls to other DLL functions return errors about invalid handles, which makes sense.
Can I compile the project in LabVIEW 2011 and save it back to a LabVIEW 8.5 compatible project file?
Thanks,
Jason Mazzotta

Bannu wrote:
Hi All,
I am also having the similar issue. I have a VI, developed in LV2010 on Windows XP machine with a dll call using "Call Library Function Node".
It is working fine in all WindowsXP machines but not in Window7 PCs.
Getting Error when i tried to open in Windows7 machine:
Error loading "DLL path....". Invalid access to memory location.
Please let me know how to make this working on both machines [XP and Win7].
Thanks,
Soumya
Way to little information to say anything useful about it. Attach your VI, explain what it should do, explain what the DLL is you try to call! You don't call your mechanicien saying your car doesn't start and expect him to diagnose the problem over the phone either with that much information.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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.

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

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 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

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 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" 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.

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

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

Call library function windows 95

Similar Messages

Maybe you are looking for