Accessing the same variables from different VIs

[Robst]

Hello:

I need to create an application where there are a bunch of variables that hold the values of some readings from tags of an OPC Server. Those readings must be accessed from different VIs, and I'm not sure in which way is it best to store those readings in order to make them available to all the VIs. I first thought that it would be a good idea to use Global Variables but I've read in many places that you must avoid the use of them.

I don't want to read the values from the OPC Server in each VI. I think it's best to have a background process that reads the values and then all the other VIs can just look at the readings already made.

Any ideas?

Thanks in advance.

Robst.

[tbob]

One way is to create a LV2 style global variable.  Search NI website for this term to see how it is done and how it operates.  Another method is to create a reference to the variable and pass this reference to each vi that needs to access the variable.  Search for examples on references.  The reference method requires wiring between vi's.  The LV2 global does not.  It appears as a subvi in all vi's, so the link is performed that way.

[Robst]

Hi:

Ok, I've seen both methods, functional globals and references. Still I have some question regarding this methods. In the case of functional globals,  if I need to share 40 variables, then I need 40 functional globals, right?, that seems lots of VI's. And in the case of references, having a reference I can wire it to a property node and to get the value of the control. I've read that this is time-consuming, Is this the approach that should be followed in the case of references? Am I missing something?

Thanks in advance

Robst.

[JLS]

Hello,

The inefficiency regarding property nodes you read about was probably a reference to the fact that they run in the user interface thread, which depending on the application and frequency of access, can cause lots of thread swapping - this takes time just like anything else on the computer.  One thing you can do in the functional global case if you don't want to have so many VIs is to have more than one of your functional globals handled by the same VI.  Remember that the functional global is really just an unitialized shift register, where actions taken on the data are determined by what case of the functional global executes.  Thus, if you're executing state A which is supposed to change functional global A, but leave functional global B alone, you can simply wire the data for functional global B through that case so that it doesn't alter its data.  Basically, the idea here is that you can have a single VI handle multiple "globally stored data."

I hope this helps!

Best Regards,

JLS

[Robst]

Hi: About the property nodes, yes, I've read they execute in the user interface thread, and that is what makes them very slow. In other thread
<a href="http://forums.ni.com/ni/board/message?board.id=170&message.id=166101&query.id=26528#M166101">here</a> ) I saw the speed comparison and the difference is overwhelming.

And about the functional globals, hey!, thanks, that suggestion about functional globals is pretty nice, I'll use it. Thanks a lot!!.

 Stars for you JSL! (And for tbob too, of course!)

Regards!

 Robst

[Jaime Rodriguez]

Are you using LV 8.0? If you are, then I suggest using the shared variable for each tag you want to publish. If you are using LV 7.0, one way to do it is trough data socket. Publish each of the tags, and then each separate VI would subscribe to that item when they need to read.

Hope this helps.

[Robst]

In Spanish:

Que tal Jaime:

Por tu nombre me atrevo a suponer que hablas español. Ahorita estoy utilizando LabVIEW 7, no había considerado la posiblidad de usar DataSocket. Voy a probar la alternativa a ver como se comporta aunque creo que generaría mas carga para la aplicación que el utililzar Variables Globales de LV2.

Saludos!

In English:

Hello Jaime:

Based on your name I suppose you speak Spanish. Currently I'm using LabVIEW 7, I didn't considered the use of DataSocket before . I'll try it to see how it behaves despite I believe that it would be represent a bigger workload to the application than using LV2 Globals

Regards!

Robst