Application Builder - Use of Global Variables

[jraoul]

Hello,

I have an application which consists one one main VI running for the user interface, and one VI running in the background dealing with CAN communications.  These two VIs must communicate using global variables.  In the main VI, I have to open a reference to the global variable VI in order to write data to it.  The application works correctly in LabVIEW environment.  However when I build the application using application builder, I receive an error with the open reference VI in opening the global variable VI.  The error given is Error Code 7: File not found.  The path to the Global variable VI is correct however.  I am pretty sure of this because in my main VI, I open up other VIs based on the open reference function and a path.

Therefore:

1) I can open references to normal VIs and use properties such as run VI without a problem.

2) This does not work for my global variable vi.

Build settings:

Im dont understand all the build options completely but the settings I use are:

1) Single target file contening all the VIs

2) All the VIs I use are located in the same folder

I hope the explaination is clear enough.

Do you have any suggestion to explain what happens and how can I make it work correctly?

Thanks

Julien

[tst]

Your usage sounds very weird. Normally, the best reason to use a standard global is that it's easy to use. You simply place it in the diagram and select the one you want. Your use case of opening a reference to the VI sounds weird.

You say that the path is correct. There is a very simple way to check this. Place a path indicator showing the path you built and you will see exactly. The most common reason for path problems in executables is if you build relative paths since the executable itself is treated as another directory, so you have an extra level. The common way to go around this is to use the Application.Kind property and if you're running in the RTE perform an extra strip. Another problem you might have is that if you are dynamically loading the VI, it will not get included in the build automatically. You have to include it manually either by selecting it as a support file or by including a VI which calls it normally.

After all that, though, my suggestion would simply be to avoid the global. If you need inter-VI communication you can use a lot of other global options like LV2 globals, named queues, notifiers, etc. or even use globals as they were intended and they will all probably be simpler than the way you currently use globals. Note that global communication in LabVIEW is very risky because you can easily create race conditions and it's important to look out for that.

[michenglaoxu]

Probably there are two reasons:

1: check you global varaible path ( which is different in development and runing environment)

2: when building executable file, check if the global variable is added into the source file, this happens sometime.

Suggestion:

You mentioned you have two vis ( user interfave and background) share on global varibal, how many exe you generated? 1 or 2? if 2, you cannot use global variable before LV version 8.0. Try to use other way for communication. In LV 8.0 and later version, you may use share variable.  If one, try to use other way. Normally, I use subvi function (see attached)  to communicate between two vis.

[jgvarner57]

What I have noticed with globals when using applications is they do not always have the default value when they are called from within an application. When I 'make current values default' in a global in the LabVIEW environment, they become static and reliable. This is because the global is a separate VI file that can be saved individually and thus its default values are saved in the global.

When you make an application, any global vi you use is embedded in the application exe and will not always have even the original defaults present when first called. I experimented with this and I saw more often than not my text, directory or other globals were blank when I first ran the application. Globals can be changed and set reliably while the application is running, but when it is closed, everything goes back to often blanks.

The trick I use is I have in the application a vi that saves my globals to a config file, and then I have the application encrypt that file for later use. The next time I start the application, it reads that separate decrypted file and populates all the globals at the beginning. This way any changes made during the program are saved for the next time that application is run. If that encrypted global file is lost, the application simply creates a new one with default constants in the global retrieval VI. That is the most reliable method I have found to use globals in an application.

[billko]

---

@jgvarner57 wrote:

What I have noticed with globals when using applications is they do not always have the default value when they are called from within an application. When I 'make current values default' in a global in the LabVIEW environment, they become static and reliable. This is because the global is a separate VI file that can be saved individually and thus its default values are saved in the global.

When you make an application, any global vi you use is embedded in the application exe and will not always have even the original defaults present when first called. I experimented with this and I saw more often than not my text, directory or other globals were blank when I first ran the application. Globals can be changed and set reliably while the application is running, but when it is closed, everything goes back to often blanks.

The trick I use is I have in the application a vi that saves my globals to a config file, and then I have the application encrypt that file for later use. The next time I start the application, it reads that separate decrypted file and populates all the globals at the beginning. This way any changes made during the program are saved for the next time that application is run. If that encrypted global file is lost, the application simply creates a new one with default constants in the global retrieval VI. That is the most reliable method I have found to use globals in an application.

---

I've never, ever seen this global behavior before.

[jgvarner57]

I don't recall this being an issue on earlier versions, but I have certainly been noticing it with LabVIEW 2019.

[RTSLVU]

---

@jraoul wrote:

I have an application which consists one one main VI running for the user interface, and one VI running in the background dealing with CAN communications.  These two VIs must communicate using global variables. 

---

Hmmm... Must they? Is that a requirement? 

A different program architecture like a QMH or CMH that have independent loops that can communicate with each other would be a better approach to this. 

[billko]

---

@jgvarner57 wrote:

I don't recall this being an issue on earlier versions, but I have certainly been noticing it with LabVIEW 2019.

---

Interesting, because LV 2019 is about the only version I've never used.

[tst]

---

@jgvarner57 wrote:

When I 'make current values default' in a global in the LabVIEW environment, they become static and reliable.

---

That is not actually correct, unless something very significant has changed, which I doubt.

A global variable VI has a front panel, just like any other VI, where you can set the current values of the controls to be their default values. This takes place immediately, but unless you actually save the VI, this change will not be persisted. Most likely, you either save the global VI explicitly or save all VIs after you make this change.

When running from an EXE, you can't save VIs, so this trick can't work. In that case, as you suggest, you have to save the values somewhere else and reload them if you want to be able to keep the values across runs. This doesn't have to be encrypted (and can in fact be as simple calling the OpenG or MGI VIs which save and load panel values, although you will need to make sure the front panel isn't removed when building an EXE), but doing that can be a protection layer against users finding the file and playing with it.

[Kyle97330]

---

@RTSLVU wrote:

---

@jraoul wrote:

I have an application which consists one one main VI running for the user interface, and one VI running in the background dealing with CAN communications.  These two VIs must communicate using global variables. 

---

Hmmm... Must they? Is that a requirement? 

A different program architecture like a QMH or CMH that have independent loops that can communicate with each other would be a better approach to this. 

---

Please note that the post you are replying to is over 15 years old...

I mean, you're not wrong in general though...