Dynamically calling vi in Windows 10

[jmohorcic]

Hi All,

I am working on a program where I want to dynamically call a VI based on selected part number. It works on my development PC (Windows 7), but not on my Production PC (Windows 10). I've stripped it down to just calling a simple program. It runs fine on Win7, but when I run it on Win10 it doesn't work. No errors, no notifications, no anything. I've tried giving both programs full admin privileges and it doesn't help. Has anyone else seen this issue at all, or have any insight into the program. I am using LV2016 currently. 

[Gregory]

What, exactly, are you using as VI Path?

[jmohorcic]

It's just a control that I map to the path of the string vi (in .exe form) attached in op

[Gregory]

Yes, but it seems like you are using the wrong path, so I want to know the exact path you are using on each PC.

[jmohorcic]

they are both ...\Desktop\string.exe

[Gregory]

Well it's not going to work with an executable file.

I wish you would just share the full paths instead of "..."

Try forming your path using a property node to make sure you are forming it correctly:

[jmohorcic]

So, if this doesn't work with exe files, is there a way to dynamically call exe and still pass info to each of them. Or is it just as simple as keeping my sub vi in .vi format and placing it an place where the main exe can access it?

[Gregory]

If the VI is in a static VI reference, the application builder automatically knows to include it in the build. Here is a slightly dated article I quickly googled with more info.

I've never actually cared to figure out how the file path is built up inside the exe, I just use a property node as shown above.

[crossrulz]

---

gregoryj wrote:

I've never actually cared to figure out how the file path is built up inside the exe, I just use a property node as shown above.

---

In 2009 and higher, it is similar to a zip file with a hierarchy.  The folder hierarchy is maintained to be exactly as your development folder structure.  So relative paths to VIs that are included within the EXE will be the same.  So for those, use Current VI Path and then Build Path and Strip Path to make the paths to the VIs you want to use.

If the VIs are not included, then you will probably want to use Application Directory to start building your paths from.

[Bob_Schor]

The following scheme works just fine in Development Mode, and also (with no change) when compiled as an Executable (I'm posting the Block Diagram as a Snippet just to get a picture quickly -- this is not meant to really execute, but it certainly does ...).

The purpose of this routine is to test 24 VISA Balances by opening and closing the VISA connection and seeing if an Error results.  A Re-entrant VI, "Verify Balance" (shown as the Purple Static VI Reference in the first For loop) takes a parameter from 1 to 24, opens a VISA connection to that VISA port, and closes it.

The scheme I use is to drop a Strictly-Typed (note the Star) Static VI Reference, wire it to a Property Node to get the Path, and also wire the TypeDef to the Type input of Open VI Reference.  Option 140 is "Prepare to Call and Collect" (I rarely use Call and Collect, but do here) + "Enable Simultaneous Calls on Reentrant VIs" (I call this type of VI a "Clone").

The first For loop starts the 24 routines, the second waits (briefly) for them to exit and keeps track of those that throw an error, which gets displayed as a Boolean array of two rows of 12 "Failure" (= Red) LEDs.

The important thing is this code works "as is" in Development Mode, and equally when built into an EXE, with only the Main VI (shown above) as the Startup VI, with no other VI specified.

Oops, I almost forgot the main point.  This code (in LabVIEW 2016, 32-bit) works on both Windows 7 (64-bit) and Windows 10 (64-bit) PCs, in both Development and Executable modes.

Bob Schor