Reading from an uncompiled VI in an exe

[MarkusSt]

I have the following situation: I have a VI that (among other things) reads an ADC every few seconds to log some temperatures. I want this VI to be running all the time, so I want to compile it to an exe that runs on autostart.

However, I also have another VI that does not run all the time and that reads the same and some additional values from the ADC. So I figured that in my first VI, I would just check if the second VI is running and if it is, instead of reading from the ADC, I just grab the temperatures from the second VI.

To do so, I use the Open VI reference function with a path constant and then check the Exec.state using a property node and finally get the values using an Invoke node. That was all working just fine until I tried compiling the first VI. Note that I cannot compile the second VI so that one remained untouched.

When I now run the compiled VI, everytime the Open VI reference is called, I get this small popup where LabVIEW searches for files (I assume it looks for the subVIs of the second VI, but it's too fast so I don't know). That closes without error but the Exec.state property node always returns "Bad" even if the second VI is running.

Now my question is: Why is that the case and what can I do to fix it? I'm also open to other suggestions.

What I want to do in short is this: From a compiled exe, check if an uncompiled VI is running and if so, read some of its control values.

I have successfully done pretty much the same thing the other way around before so I was not expecting the issues I am now facing. The only solution that came to my mind are Network Shared Variables, but I don't really want to go that way if there is a bette solution.

I hope the description of my issue is sufficient, but I can of course also whip up an example VI if necessary. Thank you for your help!

[GerdW]

Hi Markus,

---

@MarkusSt wrote:

What I want to do in short is this: From a compiled exe, check if an uncompiled VI is running and if so, read some of its control values.

---

As long as you stay within the LabVIEW IDE then LabVIEW is in control of all VIs running (or staying in memory). Now you want to do the same when running an executable: now that executable (and its RuntimeEngine process) wants to take control of all VIs in (its own process) memory.

This can/will lead to conflicts between the exe's RuntimeEngine and the LabVIEW IDE when trying to access the very same VI…

---

@MarkusSt wrote:

I have successfully done pretty much the same thing the other way around before so I was not expecting the issues I am now facing. The only solution that came to my mind are Network Shared Variables, but I don't really want to go that way if there is a bette solution.

---

I would prefer a clear API when trying to access measurement data, like a well-defined network protocol. You may use NSVs, but I prefer simple UDP/TCP protocols to contact a server from a client…

(Accessing controls on the frontpanel of a VI is not a "clear API" IMHO.)

[MarkusSt]

Hi Gerd,

thanks for your fast reply as well as your explanation. It totally makes sense that I cannot easily communicate between the two VIs if they run in different LabVIEW environments.

And I fully agree that accessing front panel controls is not a clear API or good practice for that matter. I will look into the UDP/TCP protocols you suggested but for now I solved my problem by just running the uncompiled VI on autostart. That's more a case of fighting the symptoms than fixing the root issue but it will work until I can implement a cleaner solution.