vi server usage for executables

[lebecker]

Hi All,

I've been trying to locate a good explanation and example of VIserver usage for launching executables on client PCs (XP) across a LAN from a process controller PC (Win7). What I've found for the controller is basically detailed in this snippet:

The following has been placed in the target's  .ini file at build time to enable VIserver to use an executable file (?):

server.tcp.enabled=True
server.tcp.access="+*"
server.tcp.port=3364
server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000"
server.vi.access=""
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True

So a reference to a LV application instance is opened on the target machine from the controller on a specified port, and then a VI reference

to the .vi file (another instance?) is opened on the same target for VI node manipulation. So what has been lost to me is the executable

file I'm trying to run. It cannot be wired to the path terminal to 'Open VI ref'. So this implementation requires both the .exe version and VI version

of the code I'm trying to run? I've successfully launched executables across a LAN using plink with a script file. Problem is I can't find a way

to re-start the target executables once loaded. There is most likely a C solution for this (I'll take it if anyone knows!), but since VIserver has the tools

to control execution, I'd like to use it. Also, I want to understand the linkage in the instance(s) between the VI version of the program and the .exe

version. Any help would be greatly appreciated.

lb

[amezam]

Hello Lebecker, 

Is this what you're trying to do (check last comment)?

http://forums.ni.com/t5/LabVIEW/Running-exe-by-using-open-application-and-open-vi-reference/td-p/170...

Have a good weekend!

[lebecker]

Hi,

You referenced this response from Ben (have read many of his posts) :

In modern version the exe on the target should be up and running and the VI in question should be marked as served and the access for VI Serverconfigured to allow access to the target VI (on the server). Also check the option in the build to use TCP/Ip for VI server calls.

After following his suggestions, this is the observed behavior between controller and target:

1. The VI version of the target code must be present (even if target does not have LV developer suite installed) and exe version must be loaded (opened) on the target. If the exe version is not loaded the target will refuse the connection.

2. If the 'Open App Ref' subVI is not used to establish connection to a target PC the target VI front panel opens on the controller (default LV instance?) monitor instead.

3. I'm guessing here but the 'Open App Ref' subVI establishes a linkage to the LV app instance of LV runtime engine on the target regardless of LV developer being installed or not. The 'Open VI Ref' points to the VI version of the target code, not the exe version, so that its objects and run state can be manipulated via VIserver. The exe file is not directly input to ref creation subVIs nor invoke nodes even though it does have to be loaded. 

4. Once this required duality of having the exe file loaded and VI file present on the target, the target VI can be manipulated by the controller as advertised.

Since it appears that VIserver cannot initially load the target file, I have been successful using plink with a command file to initially load and execute the target executable. However, once loaded, it now cannot be restarted by the controller using plink. But with Viserver set up the way you have instructed, subsequent launchings of the target code should be possible from the controller with the 'Open App Ref' and 'Open VI Ref' technique..

Does this sound about right? Also, if the exe build has many supporting subVIs, do ALL of them have to be present on the target PC in addition to the exe file?

Thanks for wading thru all this...I appreciate your help.

lb

[Ben]

---

@lebecker wrote:

Hi,

... 

Does this sound about right? Also, if the exe build has many supporting subVIs, do ALL of them have to be present on the target PC in addition to the exe file?

Thanks for wading thru all this...I appreciate your help.

lb

---

Full disclosure:

I skimmed what you said and my coffee is not working yet.

Could the difference between sub-VI paths in a built exe be affecting your observations?

The path to sub-VI changes when built and in fact you also have the option to use the old format which gives yet another possibility of paths to sub-VIs in exes.

As a quick sanity check when working with these situations I put an indicator on the FP of the VI's I want to target to make sure I am using the proper path.

I will now let my coffee finsih it job.

I hope I did not confuse anything with that half-brewed reply,

Ben

[lebecker]

Hi Ben,

Sorry for my delayed response. 

I sorta follow what you're saying but not totally. I have a main target VI that is built into an exe on one target with LV8.5. The built exe is then distributed to two other targets and run on all 3 targets, including the one that built the exe, over a LAN connected via TCP.  A main controller VI on another PC commands the target PCs.The exe version on the targets runs fine with just default settings in the build process, especially for 'Source File Settings' in which the inclusion type is 'Include of referenced'. I think all the files in the project default to this setting. The exe was started on each target by a command from the main conroller via plink.

I was attempting a more sophisticated control of the target exe by using VIserver. I placed the main target VI, but not the subVIs, on each target so it could be referenced by 'Open VI ref'. The exe version was loaded. The error I got, of course, was that all the missing subVIs were not found by VIserver. So I take it what you're saying is that instead of placing all 100+ support subVIs on each target, that during the build there's a way (maybe using the 'Always Included' in the source file selection?) to get the main VI to point back to the original source?

This is the final piece of this project and it's driving me nuts...Thanks for your help, Ben.

lb

[Ben]

Set the VI Server to the side for now.

The exe must be able to find all of its sub-VIs. The app builder will generally include all of the sub-VI INSIDE the exe. I old vrsions of LV the exe could be renamed as a llb and you could browse into the exe.

Modern version eliminated that method. It maybe sometime after LV 8.5 that NI changed the format of how the sub-VIs are saved for an exe. There is a option in the build to choose the old version.

So you have to have the sub-VI available on the target machine somewhere.

I THINK this paper refers to the method I learned to use yearas ago.

http://zone.ni.com/devzone/cda/epd/p/id/4364

What has complicated outr lives since then is keeping track of the application instance.

I think you already saw my posts about the magic numbers we need in the ini files so I skip that.

One of the short-cuts I have taken advantage of is that the full path of the sub-VI is not required if the sub-VI is already loaded into memory. I do that by making sure the sub-VI is called somewhere in the code. In that case, I only have to spec the name of the sub-VI once I have connected to the app instance.

There is another new item to watch for. Name mangling is when the library is prepended to the front of a sub-VI name. That is why I suggested running the exe and looking at what the path/name of the target sub-VI so I can see if name mangling is hitting me.

I may not be helping much. I have a bunch of guys that I have taugth this technique too that uses it everyday but it has been years since I had to do it myself so my memory is lacking.

Sorry,

Ben

[lebecker · Accepted solution]

OK Ben,

Your posts have prompted me to a technique to do the remote load and execute of an exe file built in LV8.5:

1. To load: The controller issues a 'tasklist' command to a target. The target produces a tasklist output file that is read by the controller. If it findsthat the target is already loaded, the controller executes it with an invoke node 'Run VI' command. 

2. If the target is not loaded, then a script file is executed on the target via plink from the controller. This command will also begin execution.

3. All subVIs have to reside on the target, as you stated, even if (as in my case) the target does not have LV Developer Suite installed.I placed theVI file versions and the exe files in the same folder.

4. The .ini file produced at build time was modified as indicated in the first message of this thread. No special settings were used at build time.

This is probably not the exact technique you had in mind but it does seem to work...thanks again for your help.

lb

[nathand]

The subVI does not need to be present as such anywhere on the target so long as it's built into the EXE.  The easiest way to do this is usually to call the subVI somewhere inside the EXE, or put a static reference to it inside the EXE's startup VI (or a subVI of it).  As Ben mentioned, once the VI is in memory - and either method from the previous sentence will cause it to be loaded - you need only provide the name of the VI, as a string, instead of a path to the VI.  If the VI is inside a library, the name may get modified and you'll need to change the string correspondingly.

[lebecker]

Right you are, Nathan. I removed the folder on the target with all the subVIs. The subVIs are present in the build, so they're embedded in the exe file and loaded when the exe is. Also, the string containing the main VI name wired to the VI path terminal on the 'Open VI Ref' subVI made this a simple implementation. Don't know how I got so tripped up on this one...Thanks for your help!

lb

[Ben]

Glad to hear you succeeded!

Ben