How to use global variables in common VIs for multi projects?

[Noriker]

Hi,

I've developed a control application with a modular structure, where I need to use many subvi's in multiple projects. The subvi's themselves don't need to be altered between projects, but they do use refer to global variables that will need to change for each project. In effect the global variables are part of an individual project configuration, such as setpoints, so the subvi's need to refer to the same global variable name, but this must be located in a different file for each project. Is there any way that the references to the global variable can be made to be a project related reference, and not a file reference? Or is there any other way of organising subvi's for reuse that gets around this?

Many thanks for your help.

[billko]

Make whatever controls you have in your global into typedefs and put them in your universal subVI library.  Instead of having your subVIs depend on the global, just bring the data in, via the typedefs you just made.  Make master copy of the global in that same library for convenience.  Every time you make a new project, just make a copy of that global and place it in the new project.That way, each project can have it's own global, yet the subVIs remain independent.

You might consider placing all the controls in your global into one typedef'd cluster.  That way, if you ever need to change that global - and you probably will, at some point - make changes to that cluster and everyone gets updated.  The good thing is that everyone gets updated.  The bad thing is everyone gets updated.  The reason I say this is potentially bad is that if you make that change to the library, you will have to release a new version of every project that uses that library.

[Noriker]

Hi Bill, Thanks very much for looking into my problem. However creating typedef does not solve the problem. The problem is labview creating conflict. Our global variable is in a while loop of subvi which is used for multiple projects, therefore we don't want to change the global variable name, but global's content is different for different projects. Labview does not use global vi in the particular project rather look for other places, causing conflict. I am sure this is not an uncommon problem. Can you suggest a way around the problem please? As we cannot bring data into while loop via wire, will queue be good way? Or using class structure? Would it be overkill? Thanks for your help.

[crossrulz · Accepted solution]

A Class Structure is still just using a wire.  So OOP will not help the situation.

Alternatives to Global Variables include Action Engines, Notifiers, Data Value Reference (DVR).  The one you might want to look into (assuming LabVIEW 2016 or newer) is the Tag Channel.  Channels are a different way to use references (at least, that is how I view them).

[Noriker]

Thank you! I think FGV might work and will try it. I have never heard of tag channel but I'll have a go and let you know the outcome.

[billko]

---

@Noriker wrote:

Hi,

I've developed a control application with a modular structure, where I need to use many subvi's in multiple projects. The subvi's themselves don't need to be altered between projects, but they do use refer to global variables that will need to change for each project. In effect the global variables are part of an individual project configuration, such as setpoints, so the subvi's need to refer to the same global variable name, but this must be located in a different file for each project. Is there any way that the references to the global variable can be made to be a project related reference, and not a file reference? Or is there any other way of organising subvi's for reuse that gets around this?

Many thanks for your help.

---

Really, the only way I see this happening is by decoupling the global from the subVI.  It shouldn't be that difficult to convert the subVI from using the global directly to having a terminal with a cluster with the same data structure as the global.  (And that's where the typedef comes in.  As the global changes, the clusters automatically adapt.)

Because the subVI now accepts data from a control hooked to the connector pane instead of directly from the global, it can accept data from anything - including a local copy of the "template" global.

[Noriker]

Hi, functional global variable works best for our application. Thank you very much for your advice. I would like to accept your comments as a solution, but I cannot find the way to do it. 

[nilsdornblut]

Hi Noriker, how exactly did you realize this with the FGV? The goal was to call up different paths for configuration files depending on the Project?

Many thanks for your help.

[Noriker]

Hi, FGV is a vi and contains no value, therefore it won't cause conflict included in different projects. Project specific values are treated as input/output of FGV (ie write/read). We actually used CVT table. Hope this helps.