LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP Get missing Sub VI in LabVIEW Run-Time .exe

Solved!
Go to solution
0 Kudos
Message 11 of 15
(963 Views)

Why not use static VI references? That usually includes the needed code automatically, and there'd by no typos.

0 Kudos
Message 12 of 15
(946 Views)
Solution
Accepted by topic author SharkoNext

So in a nutshell, this is how my real application works (All running using LabVIEW run-time and TestStand Base Deploy:

  1. Splash.exe Launches Vis to run in background via VI-Server calls
  2. Splash.exe Launches TestStand in Background
  3. Splash.exe Launches MainApplication.exe
  4. MainApplication.exe runs
    1. Launches TestStand sequence to execute based on configuration data pulled
    2. Launches Vis dynamically to run embedded in its panel window
  5. TestStand Sequences running
    1. Makes calls to dynamic Vis running in background (launched via splash.exe)
    2. Updates TS status/progress to MainApplication.exe UI

 

Because I'm making dynamic VI calls on VIs that are shared between TestStand and LabVIEW Run-Time I couldn't use source distribution or directly add all the dynamic VIs to the .exe build; NOTE that there's at least 25 vis here that are dynamically called from my exe and shared between .exe and TestStand, adding to the build breaks the ability for them to be shared because TestStand "can't find the VI's" when they're pulled into the .exe...

 

I was able to bypass these suggested methods simply by adding JSON and HTTP source VIs to be included in my exe build.

 

Strange part is I didn’t think it would work because of how I’m dynamically calling the Vis from TestStand and the potential to make them not found by including in the exe, but somehow this seems to work just fine...

0 Kudos
Message 13 of 15
(923 Views)

Thanks for letting everyone in on the solution.

 

Did I read over TestStand? I don't think you've mentioned it at all? It seems pretty relevant!

0 Kudos
Message 14 of 15
(913 Views)

No, you didn't miss a mention of teststand.

 

The real application is so complex that I was just happy to be able to reduce my issue down to a reproducible conflict with using HTTP GET in LabVIEW run-time...

 

Thank you and thanks everyone for leading me down a solution path!!!

0 Kudos
Message 15 of 15
(907 Views)