LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running a plugin executable

I'm curious as to if anyone else has experienced this and if there is a solution...

 

We have a fairly large and complex program that runs a variety of functions for us and we've added capability by creating standalone executables (plugins) that we then call as needed.

 

We have a number of these plugins that have a history of working with no problems. The way they're invoked is by supplying an executable name and path to the main program (let's call it "A.exe") and when the plugin's button is pushed on the menu, the path and name for the exe are sent to the "system exec.vi" (no command line modifiers are being used). The program starts and all is fine....  except for the newest one that I've created - Let's call it "T.exe".

 

Scenarios:

A.exe - running

 

 - Start T.exe from a command line window that I've opened myself - T.exe starts and runs perfectly.

 

- Start T.exe by double clicking the icon in Windows Explorer - T.exe starts and runs perfectly.

 

- Start T.exe using the menu button in A.exe (which launches T.exe using the LabVIEW "system exec.vi" within the A.exe program) - T.exe fails on startup stating it can't find "Get First Matched Node.vi" in "NI_xml.lvlib" along with three other vis from the NI_xml.lvlib showing the same "can't find" error before the main window of T.exe opens with a broken run arrow.

 

- Created a batch file wrapper to start T.exe

 

 - Call T.bat from a command line window that I've opened myself - T.exe starts and runs perfectly.

 

- Call T.bat by double clicking the icon in Windows Explorer - T.exe starts and runs perfectly.

 

- Call T.bat using the menu button in A.exe (which calls T.bat using the LabVIEW "system exec.vi" within the A.exe program) - T.exe fails on startup stating it can't find "Get First Matched Node.vi" in "NI_xml.lvlib" along with three other vis from the NI_xml.lvlib showing the same "can't find" error before the main window of T.exe opens with a broken run arrow.

 

I have removed the NI_xml.lvlib from "Dependencies" and added it to the main project area under "My Computer" and in the build specification I've made sure to set it to always include the NI_xml.lvlib in the build. This has had no affect on the outcome.

 

- Created a very small executable (Launcher.exe) that I can call in the same manner as above that then allows me to specify the path and program name for T.exe. Then clicking the "OK" button in there it uses the system exec.vi to launch T.exe. 

 

- Execute Launcher.exe from a command line window that I've opened myself - Launcer.exe starts correctly and then using Launcher.exe, T.exe starts and runs perfectly.

 

- Execute Launcher.exe by double clicking the icon in Windows Explorer - Launcer.exe starts correctly and then using Launcher.exe, T.exe starts and runs perfectly.

 

- Execute Launcher.exe using the menu button in A.exe - Launcher.exe starts correctly and then using Launcher.exe,  T.exe fails on startup stating it can't find "Get First Matched Node.vi" in "NI_xml.lvlib" along with three other vis from the NI_xml.lvlib showing the same "can't find" error before the main window of T.exe opens with a broken run arrow.

 

The last scenario would make me think that there's an issue within T.exe since Launcher.exe starts and runs with no problems, but Launcher.exe is incredibly simple compared to T.exe. The problem in T.exe may or may not be related in anyway to not being able to find NI_xml.lvlib methods mentioned above.

 

Any ideas?

 

 

 

 

0 Kudos
Message 1 of 22
(3,260 Views)

It seems like there is a dependency error between your main executable and T.exe.  They should be running in separate application states, so I am not sure what the conflict would be.  What version of LabVIEW were these applications developed in?  Any drivers we associated with these applications?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 22
(3,216 Views)

Hey crossrulz,

 

Yeah, my thoughts too.

 

Both are developed in LabVIEW 2016.

 

There are a lot of drivers involved, but the fact that the program can be started by double clicking or other means while the main program is running, but not through the main program is what stumps me.

 

Matter of fact there is another plugin that is an older (much simpler) version of mine with the same drivers in use that works fine.

0 Kudos
Message 3 of 22
(3,195 Views)

Correction...

 

A.exe is built in LabVIEW 8.6

 

T.exe is built in LabVIEW 2016

0 Kudos
Message 4 of 22
(3,177 Views)

What is the exact string you are writing to the System Exec VI?  According to the help, you should be sending something like "cmd /c T.exe" to execute T.exe.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 22
(3,159 Views)

Hmmm...  actually I will have to try that.

 

Right now we are just sending "z:\_addons\T\T.exe"

0 Kudos
Message 6 of 22
(3,151 Views)

I tried running it with the "cmd /c" added to the front so that the entirety of the string being sent was "cmd /c z:\_addons\t\t.exe"

 

No joy.

0 Kudos
Message 7 of 22
(3,123 Views)

Any chance it's a permissions issue? For example, maybe the account you're running with has permission to launch anything, but apps can't launch other apps (just guessing, I have no idea).

 

What happens if you right click your Launcher.exe and Run As Administrator? Does that help? Is your current account an admin, and if so does it work the same way on non-Admin accounts (or vice-versa?)

0 Kudos
Message 8 of 22
(3,112 Views)

Have you tried setting the working directory on System Exec.vi?

 

I see it's currently being launched from the Z:\ drive, presumably a network location. What if you copy T.exe locally and try launch from System Exec.vi?




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 9 of 22
(3,097 Views)

You can't just give it "z:\..."  you need the full path like "\\CompanyDomain.com\" where the drive "Z:\" is mapped to


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 22
(3,085 Views)