Mark Smith

I have a project where the structure is a top level .exe calling into libraries (llb's) of VI's using strictly-typed VI server calls. The top level .exe calls into LibraryA.llb and LibraryB.llb. LibraryA.llb also calls into LibraryB.llb. That means the VI's in LibraryB.llb that wrap the VI server calls get built into the Top Level.exe and also built into LibraryA.llb. When the Top Level.exe runs, the call into LibraryA.llb fails with Error 1003 and the message LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Open the VI in LabVIEW using File>>Open and verify that it is runnable VI Path: C:\Path to LibraryA\Interface.vi I also dynamically opened the panel with a VI server call (without trying to run) and sure enough got a broken error and the message "VI has an error of type 2002200. The full development version of LabVIEW is required to fix the errors" This is pretty cryptic - can someone perhaps explain the nature of this error? So I open this VI from LabVIEW and it's just fine. If I remove all VI Server calls to LibraryB.llb from the Top Level.exe, all runs as expected. The VI at the path above opens and runs just fine. As far as I can tell, the problem is that there's a name collision because the VI server wrapper VI's used to call into LibraryB.llb are already loaded into the Top Level.exe when LibraryA.llb tries to load them from the LibraryA.llb. Is my diagnosis correct? What's the best workaround? Thanks, Mark NOTE: I have cross-posted this to InfoLabVIEW as well

I agree with Tomi that in principle, OO code is the way to go. However, there's at least one shortcoming of the current implementation of LVOOP that you should be aware of. I recently wrote a LVClass (using LVOOP) that I wanted to distribute as "class Library" - that is, a set of VI's installed to a specific directory. As I found out, the Source Distribution build option in the Project Explorer does not work properly and that cascades down into being unable to use the project explorer's installer dialogs to build an installer. This could be a severe shortcoming for an instrument driver library that you would want to distribute with an installer. Here's my question to NI Support and their answer Question: I have a project with a LV Class. I want to 1) distribute the LV Class as part of a source distribution and 2) create an installer for the source distribution. While I can build a source distribution that includes a LV Class, I cannot generate a preview for the source distribution. This apparently prevents me from creating an installer for the source distribution, since all I can see from the Source Files dialog on the Installer Properties is <Error generating preview>. A simple example is attached. Is there a workaround? Answer: "... This limitation of the LabVIEW class is a known issue with LabVIEW 8.20, and is being addressed in a future release of our software package. There currently is not a workaround for this issue. However, I am interested in working with you to try and find a workaround. Can you please give me information about your desired behavior. Are you simply looking to move the class to another computer? ..." You could most likely get around this limitation using a third party installer if you want to go this route. Also, building a class with an "interface" like implementation (methods meant to be overridden in child classes) requires Dynamic Dispatch terminals. Methods built with Dynamic Dispatch terminals cannot be invoked using VI Server calls. This may or may not be important to your implementation, but it was an important limitation to me. All in all, I decided LVOOP in LV 8.2 is a good start but not ready for prime time. I'm interested to see what gets addressed in LV 9.x. Lastly, I don't have much experience with the third party LabVIEW OO tools, so there may be some options there that would work well for you. So, given the current state of LV, I would agree with LV Punk that using the LVlib (LabVIEW Libraries) to build a set of driver libraries would work well. The source distributions and the installer are easy and in my experience reliable using LVLibs.

I'm wondering if anyone out there has done an implementation of the XML-RPC protocol in pure G? I'm working on an application where a top-level control program is written in Java (by another developer) and deployed on a Linux X86 machine. I plan on using LabVIEW compiled to the Linux platform for communication and control with the instrumentation required and then communicate with the Java program thru the XML-RPC protocol (the LabVIEW app will become an XML-RPC server). Any thoughts appreciated - even if the advice is "you gotta be out of your mind". Better to know now if there are better options! Mark E. Smith Sandia National Laboratories 505-284-5293 mesmith@sandia.gov

I remember this same dilemma - my fix was to write a simple .NET DLL that encapsulates the call into user32.dll to get the window handle and then implement the IWin32Window interface to wrap the handle and then hand the ShowDialog the wrapped handle internal to the DLL instead of as part of the ShowDialog call from LabVIEW - might seem kind of clunky and it requires a DLL, but it works. It seems you could do the work of wrapping the handle in LV w/.NET calls after you use Mikkel's vi if there's a way to implement a .NET interface from LV - anybody know? Then you could avoid carrying around the extra DLL. But, more than once, I've found the best way to use the .NET namespace from LV is to write wrappers that expose exactly the functionality you need since the .NET syntax is optimized for C# or C++/CLI and not for LV. Example attached (LV7.1) Download File:post-1322-1170966265.zip

File Name: ActiveDirectoryTools File Submitter: mesmith File Submitted: 8 Dec 2006 File Updated: 12 Dec 2006 File Category: Remote Control, Monitoring and the Internet This VI uses a .NET 2.0 DLL (DirectoryTools) to search Microsoft Active Directory. The DirectoryTools DLL uses the System.DirectoryServices namespace. The DLL exposes some simple functionality to LabVIEW in a form more user friendly to LabVIEW than direct calls to the System.Directory classes. Important Note: This implementation will only retrieve the first property of any record that matches the PropertiesToLoad - additional instances of an identically named property in a record are not returned Using this VI - this VI was designed to return all the computers on a given MS Windows network. The default filter (objectClass=computer) along with the default PropertiesToLoad of "cn" (common name) will return the name of all computers registered on the network. Any valid filter string and property may be used. Mark Smith (mesmith@sandia.gov) Click here to download this file

If I recall correctly, you need to have the dynamically called vi call a reference to itself (and don't close that reference until you don't need the vi in memory). That will keep it in memory even if it finishes execution and the front panel closes (or is never opened)