Create single file for empirical values in labview

[smackee618]

Hi,

My labview code has a good deal of constants which will probably change multiple times once more testing is done, and these constants are located all over the place in the advanced framework. I was wondering whether there was a way to make a single file which stores all of these constants and puts them in the right places when the program is compiled.

I know that I could create a single VI with lots of controls, create global variables which link these controls to the appropriate places, and simply set the default values to be the ones I want to use, but I would rather not do that since global variables use for this purpose would cause unnecessary inefficiency (from what I understand).

Any help would be greatly appreciated.

[EricH]

If you're looking for constant values, is there a way to create global constants in Labview?

[Tanner]

I don't see how a global variable/constant would be the inefficient.

Once you create a global variable, you shouldn't have to create a VI just to set everything, last time I checked you could manipulate a global variable from it's little VI. Then you could just have the VIs where you need to use a variable from it read the stuff from the global variable.

-Tanner

[Greg McKaskle]

Global variables are quite efficient. Write a test to see how long it takes to read a million of something. On the mac laptop I'm using, an empty for loop took 2ms for 1 million iterations. Adding a double precision constant makes it 5. Changing that to a control terminal is also 5. Using a control local makes it 75, and using a global upped it to 77.

All of this was with debugging turned off for the VI. So you have a few nanosecs for this in most cases and when using something that could change at any time and doesn't have optimizations will use more like 70 nanosecs. You can afford that if you do any calculations at all.

By the way, when doing tests like this, avoid using constants for things like loop iterations. If it can, LV will optimize your entire loop to run at compile time to give you unbelievable numbers.

Greg McKaskle

[smackee618]

Originally Posted by Greg McKaskle

Global variables are quite efficient. Write a test to see how long it takes to read a million of something. On the mac laptop I'm using, an empty for loop took 2ms for 1 million iterations. Adding a double precision constant makes it 5. Changing that to a control terminal is also 5. Using a control local makes it 75, and using a global upped it to 77.

All of this was with debugging turned off for the VI. So you have a few nanosecs for this in most cases and when using something that could change at any time and doesn't have optimizations will use more like 70 nanosecs. You can afford that if you do any calculations at all.

By the way, when doing tests like this, avoid using constants for things like loop iterations. If it can, LV will optimize your entire loop to run at compile time to give you unbelievable numbers.

Greg McKaskle

Tell me if I am wrong, but I think that you are telling me that, since I will probably have other calculations running at the same time as I read from these globals, the slight speed decreases will not matter because other, much more processor-intensive tasks will overshadow them.

By the way, could you give me an example of "using constants for loop iterations" and the better alternative? Sorry about my slowness; sleep is a scarcity these days.

One more thing: somewhere along the line there, milliseconds turned into nanoseconds, and I was wondering whether that was intentional.

One more thing (yes I am starting to sound like Uncle from Jackie Chan Adventures): Tanner, thank you for keeping me from doing something extraordinarily stupidly inefficient. I didn't even think about simply using the global data VI.

One more thing: I don't know why, but for some reason I was predisposed toward thinking that global variables were really slow. I think I read about it somewhere. Does anybody know why I thought this?

[Greg McKaskle]

Milliseconds divided by one million gives nanoseconds. And yes, I was simply showing a common and accurate way of profiling stuff, though I didn't really show it.

The first picture shows a way to time this, and the second shows a way to get zero when doing something a million times.

Variables aren't efficient, but inefficient has different meanings depending on what you are doing. Since this will allow you to change code and retune on the fly without even recompiling, I think it is a good tradeoff. If it seems like it is getting too expensive, you pull the global outside of a fast loop and read it once and put it into a shift register.

Greg McKaskle

[Uberbots]

Originally Posted by smackee618

One more thing: I don't know why, but for some reason I was predisposed toward thinking that global variables were really slow. I think I read about it somewhere. Does anybody know why I thought this?

Global variables are horrendously slow if you use arrays. Labview will attempt to copy the entire contents of the global array before using it, which as you know can be quite inefficient, especially when you only need a specific element.

here: http://zone.ni.com/reference/en-XX/h...al_and_global/

[Greg McKaskle]

Yep, arrays may be it. But just to be clear, LV doesn't attempt to copy the array, it does copy the array, ditto for all data types that aren't references, they are by value. So a small array will be similar to a scalar, a small cluster, ditto. Large arrays or clusters will degrade linearly.

The reason for the copy is to support parallel program execution safely.

To get around this you make a functional wrapper that returns only the elements you want or makes the modifications you want, and this wrapper will automatically be a critical section.

Greg McKaskle