Labview unload dll empty path

In Labivew 8.2 Help, under "Call Library Function Dialog Box," it has the following tip listed:
" You can use the reference in input to unload a previously referenced library from memory. Wire an empty or invalid path to the reference in input to unload any library previously referenced by the node from memory"
Has anyone successfully done this before?
My application: I am writing a VI to operate a pulser/receiver through USB. Its functions are accessible through a dll written by the manufacturer. I am thinking that I may improve the behavior of my program if I can unload the dll at the end. I have tried wiring an empty path by using the "build path" icon with an empty string wired in, and I have the build path icon wired into the "reference in" input to the call library function node. I don't think this works, but I wanted to see if anyone has done it before. Can I see an example?

marikhu wrote:
On the event that you can free all the references to the DLL, it gets unloaded, but missing a single reference would mean it would not be unloaded at all.
If anyone knows the way to release all the references to the DLL, it would be great to check if would work for Case structures.
- Ramesh Marikhu
There isn't, other than making sure every Call Library Node that has loaded the DLL is also called with an empty path. Windows and most other dynamic library implementations (I knowHP-UNIX used to not do that at least in early versions) maintain a reference count for each DLL which is incremented with every call to LoadLibrary() or equivalent and decremented on FreeLibrary(). The OS only unloads a DLL when its reference count reaches 0.
A Call Library Node calls LoadLibrary() whenever it receives a non empty path on it's input that is not equivalent to the previous path. It calls FreeLibrary() on the previous DLL path when a different or empty path is passed to it.
When the path input to the Call Library Node is not enabled then LoadLibrary() is called for each such CLN on the configured library path when the VI gets loaded and FreeLibrary() when the VI is unloaded.
badmaster4 good: this one he agree to come with me
badmaster4 good: this one not happy to come
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Unloading dll freezes labview

Hi guys,
I am trying to unload a dll file and it seems to freeze labview. It sways happens at the last CLFN. If I disable the last CLFN node than the new CLFN freezes. I have watched it go through with the lightbulb thing and everything works fine until the last time I try to write an invalid path to a CLFN. Any Ideas?
Any help would be greatly appreciated.
Adam
Attachments:
Unload dll error.png ‏41 KB

Hi Adam,
I believe you are seeing this problem as you are calling the Call Library Function Node within the for loop. This means you will need to use another method to unload the dll.
There are a couple of methods you could use:
1. Whenever you specify the path to a dll on the blck diagram, LabVIEW will automaticaly unload the current dll and load the new one. As long as you are not trying to use an identical name while the VI is running, LabVIEW should automatically do the unloading for you
2. If you still need to unload the DLL every single time you can bundle the Call Library Function Node into a subVI that you can call dynamically from your main VI. You can do this using a Call by Reference Node. Once the subVI has finished executing it will automatically unload the DLL for you.
I can imagine I haven't explained this very well so if you have questions please feel free to post them. It may take me some time to get back with a coherent answer though.
Best Regards,
Chris
National Instruments - Tech Support

How to unload DLL

Hello,
I am using LV 8.2 to call a DLL but I am facing a unload DLL problem: the result can not be cleared from the memory even after I closed the VI. Only way to unload the DLL is to shutdown the LV.
I was told to using VI server to call a subVI which deals with the DLL. But for our application, using VI server seems not practical. Is VI server the only way to solve this problem? Anyone has an idea about this? Thank you in advance.
---Julia

"LoadLibrary (and FreeLibrary) and GetProcAddress " are used in C/C++, or CIN, right? 
These are actually simple dll's API's. You can use them in C/C++ or CIN (CIN's are obsolete), but also in LabVIEW. Only problem is that you can't call a pointer to a function in native LabVIEW. Check out Dynamic DLL.zip in the last message of this thread:
http://forums.ni.com/ni/board/message?board.id=170&message.id=39381&view=by_date_ascending&page=1
"I thought I have to use two mechines (IP/TCP) for VI server application. Just find out it may be locally controlled. I will give a try."
This won't solve the leak. The leak will still be there, but on another machine.
"PS: Sorry for the duplicated post.; I didn't know how to delete the other one."
That's OK. But if you can't delete it, at least edit it so it says "Sorry, duplicate post". If you don't, people might spend time answering questions that are already answered.
Regards,
Wiebe.

Creating a LabVIEW Shared DLL for use with C# and Strings?

Hi All,
I am trying to create a prototype for a LabVIEW Shared DLL that all the VI does is take in a string and return an upper cased string. Needless to say the DLL builds fine but when I try calling the shared DLL from C# the .NET application recieves an exception about "Ansi char arrays can not be marshaled as byref or as an unmanaged-to-managed parameter". Does anyone have an example of how to pass a string to a VI and return a string or an example of a better way of accomplishing this.
We are using labVIEW 7.1 on Windows 2000.
I am in quite a bit of a hurry to prove that this type of a LabVIEW Shared DLL VI would work. The eventual system will be passing in a string of XML with a large amount of
data and returning XML.
Thanks in advance,
Jim

Hello jprucha,
This occurs because LabVIEW DLLs are not considered managed code. As such, we need to define the C# function as unsafe to be able to call unmanaged DLLs.
You can find more information about C# and managed code at Microsoft's developer website linked below.
MSDN Home Page
Good luck with the development,
Matt F
Keep up to date on the latest PXI news at twitter.com/pxi

Question about LabVIEW generated DLL's

Hello,
I want to try programming games in either JAVA or FLASH.
What I want to know is if I can use the LabVIEW generated DDL's for use in my games, without having to need the LabVIEW runtimes installed.
(in other words, are the LabVIEW generated DLL's, stand alone DLL's as generated in for example C/C++ or other programming languages?)
Second, how good is LabVIEW in converting it's code into a DLL. Can I make complicated algorithms, or are just simple functions allowed.
Hope you guys can spare a few words on this topic.
Sincerely,
Heinen
The Enrichment Center is required to remind you that you will be baked, and then there will be cake.

Hello dan_u and thank you for your quick reply.
If the LabVIEW Runtimes are needed to use the DLL's, that is not a good option for me then. I eventually want to distribute my games over the internet, and having to sent the LabVIEW runtimes with the games is just not an option.
To bad, I'm better in programming stuff in LabVIEW then in writen C++ like code.
Sincerely,
Heinen
The Enrichment Center is required to remind you that you will be baked, and then there will be cake.

How to call LabVIEW ActiveX dlls into VB6

I'm jumping in on a project written primarily in VB6. I'd much rather wirte code in LabVIEW so what I am looking for is some example code for calling LabVIEW activeX dlls into VB6. Does anyone have example code? I need to see how the LabVIEW libraries and classes are called and used in VB6.

Hi Drewdafis,
Refer to this link for example code on calling a LabVIEW DLL from Visual Basic.
Hope this helps!
Best Regards,
Jonathan N.
National Instruments

Turning a LabVIEW built DLL into an ActiveX server

Does anyone have a list of the steps you must go thru
to convert a LabVIEW generated DLL into an ActiveX server. Do the functions become methods?

Hi James,
we have a library we deploy in three ways: as a LabVIEW library, as a DLL and as Active-X server.
In the build file for the DLL we have made each "function to call" a top level VI.
In the Active-X server each "function to call" is a dynamic VI. We created a new top level VI which will run when the server is started and stops after his window is hidden. In LV 6.x you need the winutil library to hide the window. If you close the window (through FP.Open set to FALSE) the server will stop. The window size is set to 1x1 in the VI Properties to minimize flickering on the screen during start of the Active-X server. You must check the "Enable Active-X Server" box on the "Application Settings" page in the app builder. In your client application yo
u open a reference to the server and then you can open a reference to the VI. You set/read the controls and run the VI. There is sample code for Visual Basic on the NI web site. I have also sample code for Visual C++ single and multi threaded clients.
If you are interested in the examples contact me at [email protected] and I will ask my customer to allow me to send it to you.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

User events from labview build dll

Reference to pattern
Previous discussion
I had this pattern in place in a LV 7.1 application using a LabVIEW
build DLL, but when migrating to LV 8.5 I found that User Events
created in one application instance can not be fired by another
application instance. It seems that since LV 8.x a LabVIEW build DLL
are a different application instance. The generate user event function generates an error inside the DLL stating that it is not working because it is a reference from another application instance.
Is the behaviour of a LV build DLL different than a C build DLL? Is the C build DLL part of the same application instance as the LV executable?
Is there a way the get the LV build DLL to be a part of the same application instance as the LV build executable or development environment?
Regards,
André
Using whatever version of LV the customer requires. (LV5.1-LV2012) (www.carya.nl)

Forgot to tell that I rebuild the DLL in LV 8.5, before making that conclusion.
Message Edited by andre.buurman@carya on 09-04-2008 01:12 PM
Regards,
André
Using whatever version of LV the customer requires. (LV5.1-LV2012) (www.carya.nl)

How to unload .dll from java application.

Hi,
I want to unload .dll (Library) for an specific event (Custom event).
Thanks in advance.

You can't.
The closest that you can get is to create another dll that loads the first. And have a method that allows you to unload it.

I cannot get rapidweaver5 to upload my newly created website. It keeps giving me the same error message "*** -[NSFileManager fileSystemRepresentationWithPath:]: nil or empty path argument"... Can someone tell me why?

I cannot get my newly created site to upload using rapidweaver5. I keep getting the following message...
*** -[NSFileManager fileSystemRepresentationWithPath:]: nil or empty path argument
I have checked the info in the bookmark info to be correct so I cannot understand why this is not working
Dave

I cannot get my newly created site to upload using rapidweaver5. I keep getting the following message...
*** -[NSFileManager fileSystemRepresentationWithPath:]: nil or empty path argument
I have checked the info in the bookmark info to be correct so I cannot understand why this is not working
Dave

LabVIEW built DLL's in a multi-threaded C++ app, Help Needed!

I'm working on a software application that is being developed
primarily in C++. There is a component of this larger application,
however, that is being developed in LabVIEW (for several reasons that
I won't dive into here). This LabVIEW code is therefore executed
within a C++ wrapper class that calls a LabVIEW built DLL.
All this was fine and dandy, untill we decided to multi-thread our C++
application. As a result, the LabVIEW DLL now gets called from
multiple threads simultaneously. From all of my testing, it appears
that resource locking is occuring such that only one thread has access
to the .dll at a time. If I make the .vi used to define the dll
function prototype as non-reentrant then this is what we see. As an
example, say we have 3 threads all calling the same .dll method call.
Thread 1, 2, and 3 all call the .dll within a few milliseconds of each
other. Thread 1 completes the .dll call after X milliseconds. Thread 2
completes the .dll call after 2X milliseconds, and thread 3 completes
after 3x milliseconds.
Now, changing the vi to reentrant, and running the same test, we see
Thread 1, 2, and 3 all complete the .dll call in 3x milliseconds.
While the fact that they now take the same amount of time to complete
would lead you to believe they are happening in parallel, the fact
that it takes 3x milliseconds as opposed to X milliseconds means they
are not.
Has anyone ever dealt with these issues before? Is it possible that
messing with the "execution system" for the vi will have an affect?
What if different .dll methods but still attached to the same .dll are
called from different threads? Same behavior? Is it a lost cause? Is
there no way to make code within a single LabVIEW built .dll run in
two different threads at the same? From what I understand this is
easily doable with a normal (non-LV built) .dll.
Please, if anyone has any advice in this area, let me know!!!
Much appreciated,
Jesse Hurdus

Duplicate post.

Prevent application from unloading dll

Hi
I have created an application that is made up of primarily two vi's, with one calling the other. The second vi, or the one that is called in turn calls/loads a dll. Now my problem is that before creating an application my vi's worked great since the dll did not get unloaded until labview was exited, however with the application it seems like if i close the second vi, or the one that calls/loads the dll then the dll is unloaded. Is there anyway to keep the dll in memory until the whole application is closed and not just the vi that calls the dll.
The solution I have used till now is to call the dll from both vi's but I rather not take that approach
thanks

reza_sed wrote:
Hi
I have created an application that is made up of primarily two vi's, with one calling the other. The second vi, or the one that is called in turn calls/loads a dll. Now my problem is that before creating an application my vi's worked great since the dll did not get unloaded until labview was exited, however with the application it seems like if i close the second vi, or the one that calls/loads the dll then the dll is unloaded. Is there anyway to keep the dll in memory until the whole application is closed and not just the vi that calls the dll.
The solution I have used till now is to call the dll from both vi's but I rather not take that approach
thanks
You don't need to call a DLL in order to have it in memory. As long as one VI in your VI tree has a reference to a DLL, and the according Call Library Node is not set to provide a dynamic DLL path (LabVIEW 8.2 and newer feature) that DLL stays in memory. No need to ever call that Call Luibrary Node. If another VI then gets into memory referencing the same DLL, LabVIEW will ask Windows to load that DLL too, but Windows seeing that the DLL is already loaded will only increment its internal load reference count.
So having a Call Library Node (or a subVI containing one) in your main VI will be enough to keep the DLL loaded. You can code something like where you put this SubVI in a case structure whose frame never gets executed. But do not disable that case by a diagram constant since LabVIEW will then optimize out the entire digram when you ever are going to build an application. Instead wire the case to a front panel control whose default value is set so that the frame will never be executed.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

LabPython does not function after being built into an executable application (am i missing DLLs or Paths?)

Greetings!!
I have recently been playing around with the amazing power of Python in Labview and have built some very functional VIs that utilize this tactic. However I now find myself at a bind. Everything runs great in the IDE, but not so great as a standalone application.
i am running:
Windows 7 64bit
Labview 2012 32bit
Python 2.7.3 32bit
My build specifications configuration attempts have all failed to run Python, and the application typically always return a very non descriptive error such as:
PYTHON New Session__ogtk.vi->NameOfMyVIFile.vi
I have tried adding DLLs to the "always include" section of the build spec.
DLLs such as:
Lvpython.dll
pytscript.dll
and I have even tried including them in both the support directory and the caller's directory to no avail. I have even tried placing the entire application + supporting files in my main Labview and python directories just to see their behavior with no apparent differences.
so now I’m left with no options that i can think of. and I'm sure I have crawled around Google so much now that I’ve read all the same posts and websites nearly three times already.
Please help me debug this!! I’m sure it’s something super simple but not very obvious that I’m missing.
I hope everyone has a great day, and thank you!
Grant.
Solved!
Go to Solution.

My python installation folder is "C:\Python27" and python27.dll is located in there.
initially i ran the "PYTHON Set Server Path" with an input string equal to: 'C:\Python27\python27.dll' while in the IDE. i have read however that (as long as the system path in windows is configured correctly) passing a string of just 'python27.dll' would work, but i did not try this.
after that the "PYTHON Script Node" is what i used to test LabPython and all's ok in the IDE but not in applications.
i have also tried this as an executable:
Which porduces this:

I get error 998 when calling a LabVIEW buildt DLL from MSVC++

I created a DLL in LV 6.0.2. This DLL contains 39 VIs and controls. 13 of the VIs are exported, the others are subVIs, which one of them is a dynamic VI.
I do not have all connectors used by defining the VI prototype in the build file for the application builder.
Using this DLL I get four effects:
From LV 6.0.2 FDS all works fine until I quit LV immediatly after the application VI stoppes. Then LV wants to save some of the VIs of the DLL.
If I do the same but close the VI before I quit LV one want save anything.
After Building an exe from the application VI and running the exe all works fine. The VI will only stop and if I close or quit noone wants to save something.
Then I built an application with M
SVC++ 6.0 using this DLL. There will be no errors or warnings during the build. If I start the application i get an error message dialog with the number 998 stating "system error loading LV Runtime engine. My application needs a Version 6.0 or compatible Runtime-engine". The path to teh Runtime-engine is given in the dialog and the lvrt.dll there has version 6.0.2.
Does someone run on such a problem?
Has someone a solution to this?
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Waldemar,
I. LabVIEW wanting to save VIs
The DLL created is just a group of VIs, not actually compiled DLL code. When the subVIs are called, they might be cached from the disk copy, not the one in the DLL. LabVIEW then loads the separate copy of that subVI. It will then ask if you want to save changes because there were value changes when it was run (this makes since) or it is in LabVIEW 6.0 version and has not been mass compiled for LabVIEW 6.0.2. When it is compiled to an exe, the search path for the subVIs goes through the executable and not the LabVIEW development environment. Also, saving VIs is not an option in an executable so the save dialog does not pop up.
II. MSVC++ error
This is actually a Microsoft issue. It has something to do with static and
dynamic linking of the MFC DLL. Our R&D engineers have verified this with projects created with no LabVIEW code at all (that is why we believe it to be solely a Microsoft issue). There are three options at this time:
1. Link with the DLL form of MFC.
2. Do not link with the .lib from the LV DLL, instead use LoadLibrary and GetProcAddress to dynamically load the DLL and call the function.
3. Use the VC delayload feature to make the LV DLL not get loaded until the first call is made into it. See VC help on "delayload" for information on setting this up.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

How do I call a LabVIEW created DLL from within Microsoft Excel (VBA)?

Hi,
I'm trying to get Microsoft Excel 2003 to call a function stored in a dll that I created using LabVIEW 7.1. The function is very simple and is called "binary_file_to_ascii". Basically it just reads a LabVIEW created binary spreadsheet file and outputs the columns as float arrays.
The function arguments are as follows:
INPUT : String that contains the path to the binary spreadsheet file
OUTPUT : Number of rows in the spreadsheet
OUTPUT : Number of columns in the spreadsheet
OUTPUT : Float array containing the elements in column 1
OUTPUT : Float array containing the elements in column 2..
OUTPUT : Float array containing the elements in column 11
However, for some reason there is something wrong with my VBA code and/or the way I created the DLL in LabVIEW because Excel crashes when it loads my DLL.
What do I need to change in my VBA code or my LabVIEW DLL build settings to fix this?
I've attached to this post a ZIP file that contains all my code and a sample binary file.
Your help with this will be much appreciated. Thanks!
Richard
P.S. Here is the VBA code I'm using:
Private Declare Function binary_file_to_ascii Lib "C:\temp\binary_file_to_ascii\binary_to_ascii.dll" _
(ByVal binaryFile As String, ByVal nrows As Long, ByVal ncols As Long, ByVal column1 As Variant, _
ByVal column2 As Variant, ByVal column3 As Variant, _
ByVal column4 As Variant, ByVal column5 As Variant, _
ByVal column6 As Variant, ByVal column7 As Variant, _
ByVal column8 As Variant, ByVal column9 As Variant, _
ByVal column10 As Variant, ByVal column11 As Variant)
Private Sub load_binary_spectra()
Dim nrows, ncols As Long
Dim col1(), col2(), col3(), col4(), col5(), col6(), _
      col7(), col8(), col9(), col10(), col11() As Variant
Dim lRetVal As Long
Dim spectra_path As String
    spectra_path = "C:\temp\binary_file_to_ascii\sample_binary_file\sample_binary_file.dat"
    lRetVal = binary_file_to_ascii(spectra_path, nrows, ncols, _
              col1(), col2(), col3(), col4(), col5(), col6(), _
              col7(), col8(), col9(), col10(), col11())
    MsgBox (spectra_path)
End Sub
Message Edited by Richard Ballantyne on 07-25-2007 02:39 PM
Message Edited by Richard Ballantyne on 07-25-2007 02:39 PM
Attachments:
binary_file_to_ascii.zip ‏192 KB

Hi,
I don't know anything about Visual Basic, but here's my guess.
When you load the DLL with this line of code
Private Declare Function binary_file_to_ascii Lib "C:\temp\binary_file_to_ascii\binary_to_ascii.dll" _
(ByVal binaryFile As String, ByVal nrows As Long, ByVal ncols As Long, ByVal column1 As Variant, _
You are defining how the parameters are sent. It seems that all are sent by value (ByVal), but in the DLL header, some of the function's
parameters are defined as pointers(see the function prototype below, look for asterisk(*))
void __stdcall binary_file_to_ascii(PStr binaryFile,
                                                long *numberOfRows,
                                                long *numberOfColumns,
                                                float column1[],
                                                float column2[],
                                                float column3[],
                                              float column4[],
                                                float column5[],
                                                float column6[],
                                                float column7[],
                                                float column8[],
                                                float column9[],
                                                float column10[],
                                                float column11[]);
Can you define in VBA that you want to use pointer instead? Maybe by using ByRef (as by reference).
Hope this helps.

Labview unload dll empty path

Similar Messages

Maybe you are looking for