We all want to be able to reuse code and a good way of accomplishing that goal is by repurposing executables that you wrote for other projects. The problem is how you control them. Last week we started addressing this challenge by looking at some of the general tools that are at our disposal for manipulating executables — regardless of where you got them. This time out we will complete the discussion by looking at some of the things you can do that are specific to LabVIEW-created executables.
First, we need an executable
As the title says, if we are going to talk about making VI Server calls to an executable, the first thing we need is an executable — and an executable, we have. Although the functionality it implements is, to be honest, rather sparse, it is sufficient to demonstrate what we need. Here’s what its front panel looks like:
Starting in the top left, it sports an indicator where you can see the command line that was used to launch it. Immediately below that string is an indicator showing the current time, a button for stopping the program manually, and a pair of LEDs that indicate when two different events are triggered: Application Instance Close?
and Panel Close?
.
To the right is a path indicator that displays one of two different paths depending on the state of the checkbox that is next to it. Below the path indicator are two numerics. One is the PID of the instance that is running. The other is the TCP/IP port number that was assigned to the executable when it was launched. Note that if you don’t provide a port number in the command line parameters, the executable will terminate almost immediately — though you may see it briefly appear in the Windows Task Manager.
Handling the front panel
Most of the code that makes this interface work is pretty straight forward, so I won’t take the time to describe it. The one exception is this bit in the initialization logic:
The reason that I’m pulling it aside for special attention is that it illustrates (at least part of) the solution for a problem that you will encounter the first time you create a VI that is designed to run entirely in the background. The heart of this problem is mismatched expectation: When LabVIEW runs an executable it expects to open the window associates with the top-level VI. You, on the other hand, wanting the executable is run unseen in the background, expect the window to stay closed. Consequently, what happens is that LabVIEW opens the window and starts the VI running in that order and your code immediately hides the front panel. What the user sees is a windows that open and then immediately closes without explanation, and if there is one things that worries users more than things happening too slowly, its things happening too fast — like windows flashing open and then closing.
The solution lies in a VI property called Transparency
. The setting to control it can be found in the custom appearance dialog.
When the box is checked and the percentage is set to 100, the window will be open but totally transparent. Hence, when the runtime engine launches the application, the window will still open but it will be invisible. A moment later, the code above will hide the window and set the transparency to 0 so that when we do decide to open it, we will be able to see it.
VI Server Operations
Last time, I presented this block of settings from the application’s INI file. Before we continue, we need to take a moment all consider what these settings mean — at least to the extent that anyone knows what they mean…
server.tcp.enabled=True ; server.tcp.port=3363 ; server.tcp.serviceName="" server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000" server.vi.access="+*" server.vi.callsEnabled=True server.app.propertiesEnabled=True server.vi.propertiesEnabled=True server.control.propertiesEnabled=True
The first four parameters in this list control overall access to the application via TCP/IP. Consequently, they are the four that you are most likely need to muck with:
server.tcp.enabled=True
: This setting enables the TCP/IP interface that VI Server uses. If this setting isFalse
, nothing is happening.; server.tcp.port=3363
: This setting specifies the port that the associated TCP/IP listener will be monitoring for a connection. Note that I have this line commented out because we will be assigning this value via command line parameter.; server.tcp.serviceName=""
: Also commented out, this optional parameter allows you to define a name that you can then use to reference the application, instead of a Port number.server.tcp.acl=???
: This setting defines the TCP/IP access control list (ACL) — or who is allowed to connect to the application. Already I can hear you wondering, what is the deal with that long string? Well, if you ever find out be sure and let me know. The bottom line is that the original interface included an ACL that simply listed the IP addresses that were and were not allowed to access the application. For reasons unknown, NI decided to change this common sense approach to something more enigmatic. So how do you generate this string? Glad you asked. According to LabVIEW’s documentation, you need to set up your development environment to have the same access list as you want your application to have, and then copy and paste the resulting string from LabVIEW’s INI file to your application’s INI file, seriously…
The remaining parameters specify in one way or another the specific resources that the remote program can access in the target application.
server.vi.access="+*"
: This parameter contains a list of VIs that are accessible through the VI Server interface. The default value shown allows access to all VIs.server.vi.callsEnabled=True
: This parameter specifies whether the remote program is allowed to run VIs contained in the executable. We leave thisTrue
so I can demonstrate that ability.server.app.propertiesEnabled=True
: This parameter gives the remote program access to the executable’s application-class properties — like the names of all the VIs currently in memory.server.vi.propertiesEnabled=True
: This parameter gives the remote program access to the VI-class properties of individual VIs. This category include things like a reference to the VI’s front panel.server.control.propertiesEnabled=True
: This parameter gives the remote program access to the properties associated with individual controls on VI front panels. For example, you need to have this parameter enabled to do things like programatically set the value of a control. This value isTrue
as I will be demonstrating this ability as well.
Finally, I want to state one thing that I hope is obvious. All these “security” settings are contained in a plain text file that can be edited by anyone who knows how to use a simple text editor. The point here is that while recent versions of Windows are making it harder and harder to modify files in the “Programs” directories, it is not by any stretch of the imagination bullet-proof. Hence, if there are truly sensitive things that need restricted access, don’t depend on these settings.
What we can do with these controls
So let’s put some of what we have been learning about into action. If you download the code from the SVN repository you will find, in addition to the source code, a compiled executable. For the following tests, you can either run the executable I have included, or compile it on your own — it’s up to you. You will also want to be sure to update your copy of the toolbox as I have added a couple useful VIs. One of the executable management VIs is where we will start:
Launching the Executable
Start by opening small test executable.lvproj
and then open the routine Launch 3x.vi
. It’s job is to launch three copies of the test application (small test executable.exe
) so on the front panel click the path browser button next to the path control and navigate to and then select the test application. Now, run the VI.
When it finishes, launch the Windows Task Manager. Nothing new under Apps, or Programs (depending on your version of Windows), so look in the Background Processes. Ah, there’s the executable, but why is it listed here? And why is there only one instance? The VI clearly looped 3 times, and there were no errors. Go to the directory where the test application is located and open its INI file. There are your answers. There is only one instance running because the INI file has multiple instances turned off, and the one executable that did launch shows up as a background process because the INI file also says to hide the root window. Leave the root window setting the way it is, but change the AllowMutipleInstances
to True
, and save and close the file.
Now back in the Task Manager, abort the one instance of the test application that is running now, and rerun Launch 3x.vi
. You should see when it finishes that there are now 3 instances of the test application running. The instances were given sequential TCP/IP port numbers from 3365 to 3367.
Firing Remote Events
The next thing I want to do is open the front panels of the 3 instances so we can observe their operation. Now if you look at the test application’s source code, there is a UDE that will make the front panel visible, so all I need to do is fire that event. But wait, those are three instances of a compiled executable — you can’t fire events in other executables! Well actually, you can. To see how, open the test VI, Open the Executable’s Window.vi
.
No magic here. All the code is doing is dynamically running a VI. But check out the function before Open VI Reference
, it’s called Open Application Reference
. Its job is to open a reference to a copy of LabVIEW or the LabVIEW runtime engine that is running somewhere else. That “somewhere else” is defined in terms of a machine name
and a port number or service name. The machine name can be a DNS name, an IP address or (as in our case here) localhost
to point to the local computer.
By the way, if you think it sounds like I just said that you could make this same code access an executable residing on a remote computer by simply changing localhost
to an IP address, your right. I did just say that.
But as cool as that feature might be, how does it allow me to fire an event in a compiled executable? Look at the name of the file being run: Open Window.lvlib:Generate Event.vi
. It’s the VI that fires the event, and since VIs called in this way actually execute in the remote LabVIEW environment, the event gets fired in the targeted executable.
To see this code in action, run it three times with the port number 3365, 3366 and 3367. Three windows will open.
Setting Control Values
Another way of interacting with an executable is to directly manipulate controls on its front panel. However, if the target VI is event-driven like our test application, we need to remember that there is a difference between setting a value and firing any value change events associated with that control. If all you need to do is set a value, there is a VI method called Control Value:Set
that will do the job nicely. However, if you want to fire the value change event you have to set the control’s Value(Signaling)
property — which frankly is a bit more work.
This picture is the block diagram of the test VI Toggle the selector checkbox.vi
, but the good news is that for this little bit of extra effort, you can set (or read) any control property that can be changed while a VI is running.
Shutting Down the Executable
Finally, we need to be able to stop an application that is running. But the problem here is figuring out how to test it such that we can see that it really did what it was supposed to do. The solution is to turn to the trace technique we discussed a while back when we were learning about command line arguments. I have written the code such that if the executable is run with the argument “d1” in the command line, the code will write a line to the trace file saying how the instance was stopped. And to help demonstrate how this works, I have created a test VI (Stop the Executable.vi
) that can execute some of these termination paths.
To start off, leave both controls in their default state, and run the VI. This example stops the targeted executable by clicking the Stop
button on its front panel. The instance with the port number 3365 will immediately close.
Port Number
to 3366
and set the Method
control to Windows shutdown - Forced
. This example stops the targeted executable by telling to Windows to abort it. The instance with the port number 3366 will immediately close.
Finally, we want to test the remaining instance’s response to the Application Instance Close
event. To do that, restart your computer now. (That’s right, restart your computer. Don’t stop anything, don’t shut anything down — just restart.) When your computer is restarted and you are logged back in, go to the directory where the test application is installed and open the trace file. You will see two lines that look something like this:
07:29:39 05/24/2015 -- Shutdown 3365 -- Just Stop 07:42:52 05/24/2015 -- Shutdown 3367 -- Appl Inst Close
The second line shows that when you restarted your computer Windows did in fact generate the Application Instance Close?
event and the application caught the event. You’ll note that there is no entry for the instance with the port number 3366. Remember, we stopped it by forcing an abort and a Windows abort is very much like clicking the red abort button when LabVIEW is running a VI: It just stops. No orderly shutdown. No deinitialization.
A Small Test Executable — Release 1
Toolbox — Release 9
The Big Tease
So that was, I hope, interesting. Starting next time I’m going to start delving into how to use LabVIEW code as the data collection and control backend for an application that has as its only customer-facing interface a web site. While there are many companies offering options that claim to be developer-friendly I have found that many of the marketing claims are largely based on FUD (Fear, Uncertainty and Doubt). Simply put, they build up a “strong man” of supposed complexity and complication, and then tell you that the best (and perhaps, only) way to get past this obstacle is to buy their product. The truth, however, is that their “strong man” is really made of straw, and if you understand how it all fits together, doing it yourself isn’t really very hard.
Until Next Time…
Mike…