programmatically select global variable object

[clink283]

Hello all.

I have a rookie question that may have an easy answer (or perhaps you can direct me to a different method which is fine too).  I’m using a global variable in an instance where it’s controlled by a parent VI and read by multiple children VIs.  The global variable contains Boolean switches, each with a specific name.  

If possible, I’d like to make the ‘child VI’ more generic and programmatically flexible so that I don’t have unique children.  That way, instead of four children, I just have one (makes debugging easier).  Here’s the crux of my question:  selecting which object is assigned to the global variable on the block diagram is done by clicking on it with the mouse – can I instead do that programmatically?

More specifically, when using the global in children VIs (as instructed in the “Creating Global Variables” section of the help files), you can select the global vi and add it to your block diagram.  The next step is to select the front panel object to associate the placed variable with the proper data (you do this by mouse clicking the node you just created – see the attached image).  My question is, can I select the object associated with the placed node programmatically instead of needing to mouse click on it?

Cheers!

[aeastet]

You should look into enumerated values and type defs or strict Type Defs and use an action engine.

[Christian Mergl]

I totally agree with aeastet. You should use a proper way to select what value you need to pass instead of missusing a global variable. Either create an Action Engine (aka Functional Global Variable) or use Single Process Shared Variables instead which can be accessed using the Shared Variable API. This gives you the ability to select in runtime which variable you want to read.

That beeing said. You can programmatically change the control you would like to read of the Variable using the "CtrlName" Property of the VI Server Class "Global".

You need to have VI Scripting enabled.

Christian

[DFGray]

Note that using scripting means the change cannot occur at run-time.  Given you have all booleans, you can get the same behavior at runtime by converting your cluster to an array and simply indexing the one you need.

I would recommend a data value reference or local shift register instead of the global, but that is another conversation...

[SteveChandler]

There is a better way of doing this as the others have already pointed out. But if you must you can use a case structure with a case containing each of the globals. Here is an example using locals. This of course only works if they are all the same type, otherwise you have to use a variant.

[clink283]

Of course!  A case structure works for what I'm trying to do - thanks Steve Chandler.

That being said, I'm open to looking into the action engine and other suggestions (thanks for those too).  My actual code is more complex than the example I gave, with up to 16 children VIs (each utilizing timing sensitive structures and queues to pass info back to the parent).  Is there a reason why globals are so bad?  If the case structure method works, what are the pitfalls that I could encounter?  If this is too generic of a question just let me know, this is my first time utilizing global variables.

[SteveChandler]

Globals are not bad but they can lead to problems if you are not aware of the pitfalls. If you have a single writer that gets rid of a big part of the issues. Multiple writers have to be synchronized in one way or another. Another problem is that when you read a global (or local) variable you do not know if what you are reading is new. The writer has no way of knowing if anybody has read it. You can programatically determine if it changed but if two writes had the same value there is no way to know you read them both. Sometimes you don't care about that but sometimes you do. If that is the case then a notifier will let you know about two successive writes of the same value. There are other problems related to performance because of data copies as well.

Also your problem is screaming LVOOP with your mention of children VIs.

[Christian Mergl]

---

@Steve Chandler wrote:

There is a better way of doing this as the others have already pointed out.

---

Even Single Process Shared Variables with their API Interface would be better as Globals:

Using this VI to read the variables gives you the ability to reference them with a string (Link to Variable). You may have to add an additional variable in future versions of your code, where you just need to add the new variable to the project and pass the string to the VI without changing the code. Single Process Shared Variables are based on Global Variables, which are usually just a bit faster. Single Process Variables can easily be converted to network variables.

However, I agree with Damien that Data Value References would probably be the best sulution.

Btw, there is a good KB talking about Globals: Are LabVIEW Global Variables good or bad, and when is it ok to use them?

Christian