This LabVIEW Tip shows how the VI Server may be used to troubleshoot a built executable. The VI Server allows connections between instances of LabVIEW, with full functionality for LabVIEW development environments, and more limited functionality for LabVIEW built executables.
The front panel and block diagram of a simple VI are shown below:
The subVI called is:
The subVI has a defect that will effectively lock up the program if the subVI’s close box is used. When the top level VI is built into an executable, three files result:
By default, the VI Server of the built executable is disabled, but we can enable it by editing the ini file so that it contains the following settings:
After saving the settings and restarting, the executable will begin listening for VI Server connections. Now, if we click on the “Call SubVI” button and then click on the close box of the SubVI window, we are ready to demonstrate using VI Server. In this state, the application is hung because no code in the top level VI can execute until the execution of the subVI completes. However, the subVI cannot complete until the done button is pressed, which cannot happen since the subVI window is not open.
In the LabVIEW development environment, we can open and run the Tool VI shown below. Note that the Application Property “ExportedVIs” is used. This property is like “All VIs In Memory”, but it works for built executables:
This Tool VI must be run with the Port Number that was specified in the executable’s ini settings. The “hung” subVI is automatically displayed in the Tool’s list of VIs. The Execution state of the vi is seen to be “Running”. The Tool VI can then be used to command the subVI to show itself, and the Done button of the subVI can be clicked.
In the steps above the VI Server was used to inspect the state of a VI running in a built executable. The front panel of the VI was also opened. This ability of the VI server is very useful when traditional debugging cannot be used. For example, it may not be possible to install the LabVIEW development environment on the target computer. Nor may it be possible to change the built executable for a more debuggable executable without invalidating configuration requirements. In the example above, the software defect was obvious, but in many scenarios the defect may be hard to discover and the method of using the VI Server to troubleshoot an application is useful.
The VIs used for this example are available for download in the zip file below: