Jim Kring

Correct, you can only call one DLL at a time this way. Rolf's suggestion (to write the linker info to the VI and change the called DLL) was also on my mind but this method requires 1) That you be in the development environment, 2) have access to scripting, and 3) understand what linker info is. So, I avoided that solution. Actually, maybe there is another way to do it. I think that the link to the DLL path is stored in clear text, within the VI (binary) file. If you used a fixed width path like "My_Dynamic_DLL_NNN.dll" you could do a character replacement of the VI's binary information -- for example "My_Dynamic_DLL_001.dll", "My_Dynamic_DLL_002.dll", etc. This could allow you to open multiple instances of the DLL.

Take a look at the LabVIEW Data Tools (lvdata) package of the OpenG Toolkit. That's exactly what this tool does.

Here is a way that should work, although I have not tried it: Create a VI named something like "DLL_Wrapper.vi" with a Call Library Function that calls the DLL. However, create a copy of one of the DLLs and name it something like "Dynamic_DLL.dll" and have DLL_Wrapper.vi call Dynamic_DLL.dll. At run-time, copy and rename the specific DLL you wish call as Dynamic_DLL.dll and place it in the same directory as DLL_Wrapper.vi (or the location where DLL_Wrapper.vi expects to find it). Then, open a reference to DLL_Wrapper.vi which will load it and Dynamic_DLL.dll into memory. Use Call By Reference to call DLL_Wrapper.vi and thus Dynamic_DLL.dll. Then close the reference to DLL_Wrapper.vi, which will unload DLL_Wrapper.vi and Dynamic.dll from memory. Repeat, as needed.

I'm taking it slow. So far, I have only converted one project to LabVIEW 8. However, I use OpenG Builder to build this application, and it uses a custom installer also written in LabVIEW.

I am trying to programmatically generate a list of information about all NI hardware installed on a machine. I want to be able to read the model and serial number of these devices so that this info can be sent to a corporate database. I am dissapointed by the fact that the list of devices returned by the DAQmx System::Devices Names property is not complete. When I go to MAX, I see a list of about 7 DAQmx devices, but the DAQmx System::Devices Names property shows only two. Why would this be? I did find a set of VIs under the NI-SCOPE palette called NI-ModInst that looks interesting. It looks like this set of VIs can programmatically obtain device info for NI-SCOPE, NI-FGEN, NI-DMM, NI-HSDIO, NI-SWITCH, and NI-RFSG instruments. This did find two of my high-speed digitizers as NI-SCOPE devices, but it failed to find my Arbitrary Waveform Generator (ARB) board as an NI-FGEN device and my digital multimeter (DMM) board as an NI-DMM device. Any thoughts? :headbang:

Finder, is sort of the Mac equivalent of Windows File Explorer. You can launch the Windows File Explorer from the command-line (System Exec), by issuing the "explorer" command.

Each LabVIEW version has the capability to down-convert to the previous version of LabVIEW. So, you will need 6.1, in order to convert to 6.0.

Hmmm, I just ran MAX and got this message: I went into the NI License Manager and noticed that the Vision 7.1 components (Vision Assistant, and Vision) were no longer activated. I did a right-click > activate, and it activated instantly. However, I am still annoyed -- that's 10 minutes of my life that I will never get back.

There are so many java components, which are cross-platform by nature. If LabVIEW could embed/use these, then it would open up a lot of options.

There's an old saying... "You can lead a horse to water, but you can't make him drink"

Great :thumbup:

You can use the NET USE command, using System Exec to execute the command line.

Kennon, thanks for this post. This is just what we need. Also, I have a quick question: How can we create a new application instance, similar to what the Application Builder now does?

Take a look at this. It is your only hope.

Also, you can also have Windows open the file in Excel by calling it from the command-line using System Exec. Just pass the path to the file, as the command string and let Windows do the rest. This method will also work if your have OpenOffice registered as the handler for XLS files.

I have posted info on how to do this here:

How can I access the App.AllVIs property of the user's (main) application instance (and perhaps project application instances) from within the NI.LV.Dialog application instance? We are having issues with OpenG Builder in LabVIEW 8.0 that are affected by the fact that the App.AllVIs property only returns the list of VIs within the application instance of the calling VI.

Let's imagine that OpenG has a function called "Trim Whitespace.vi" and NI thinks that it is so great, that they rip-off also create a function called "Trim Whitespace.vi" and ship it as part of LabVIEW, in vi.lib. Now, any time that someone opens a project that uses the OpenG version of "Trim Whitespace.vi" it could potentially relink to the NI version. This is a very bad scenario, in more ways than one. We can fix this problem by name-mangling all of our VIs prior to shipping them. Then there is no possibility that the VIs will accidentally relink to other VIs of the same name. This is actually a common practice and people have been doing it for a very long time -- commonly adding a prefix, such as "COMPONENTNAME FunctionName.vi".

This would make a great addition to the LabVIEW FAQ.

There are several things that the LV App Builder uses to determine whether or not the FP needs to be preserved. For example, if it has the Open Front Panel When Called attribute set to TRUE, implicit control property or invoke nodes on the BD, or control reference constants on the BD.

A VISA resource will coerce to string. See the following illustration:

They're so tricky. Here is the new link: http://labview8.ni.com/evaluation/labview/pc/labview_80.exe

LabVIEW 8.0 Evaluation LabVIEW 8.2 Evaluation Can be activated after the expiry to a full version upon purchase. Complete list of LabVIEW Evaluation Software. Have fun

You need to parse and construct data strings and type descriptors. This is not trivial. You might as well use the OpenG tools -- why do you think that you shouldn't use them?

Yes, you can read "<LabVIEW>\manuals\datastrg.pdf" and write your own tools.