Preserving Global Variable Functionality with Application Builder

[agriffin0]

I am working with two vi's in the same project which will be compiled as separate executables using Appplication Builder. The first one allows me to control and read out positional data for a stage controller. The second vi reads temperature and time data from an Optris USB infrared camera. I have successfully used global variables to transfer the positional data from the Position VI to the Temperature VI and write the position, temperature and time data to a file in the development environment. When I build my applications this functionality fails with no errors or way to determine why. Since the project works in development, I can only assume that this must be some incorrect setting or path in Application Builder. I'm including the entire project so that my Builder settings can be analyzed, thanks in advance.

[santo_13]

Global variables scope is limited to within an application. If you need two applications to communicate, you would need to look at other methods such as TCP port.

[BertMcMahan]

If both VI's are always going to run, you could use a single "launcher" VI that dynamically launches the other two. Run the launcher VI in your application builder.

Or, if one will run all the time and the other only some of the time, you could have a button to launch the second VI from within the first one.

Or use subpanels and combine the two.

[Yamaeda]

Or change the Global to a Network shared global.

[crossrulz]

---

@Yamaeda wrote:

Or change the Global to a Network shared global.

---

Sure, if you want your variable to be dog slow and wide open to anybody on your network being able to change that value.

Spoiler

I am a defender of Global Variables, but I fully believe that Network Published Shared Variables are actually evil.

Back to the original issue...There are 2 solutions here:

1. Combine your two applications into a single application.  You apparently already have this in the development environment.  So with what we know, this would be the simplest solution.

2. Create an interface for the two applications to communicate.  TCP/IP is what is typically used here.  In theory, you could also use Network Streams or UDP.

[agriffin0]

Thanks everyone for your ideas. It sounds like the TCP/IP solution is going to be the way to go, combining these two individual programs would be an option, but a difficult one at best due to the complexity of one of them and the way it was implemented. I'll give the TCP solution a look see and report back.Thanks again!