Need features of global variables but want to avoid re-writing to memory

[peter-biomed]

I am making a program with a number of simultaneous loops that will be sharing several variables. Most of the variables are of size 1 or small arrays, so I am not too concerned about the constant re-writings involved. However, I have one rather large data buffer (3D array containing 200Kb+ of data). The buffer will be of a set size. In the various loops, the buffer will be accessed for updates (generally with Replace Array subset), and read from to get average values and such. I'm using semaphores so that none of the loops interact negatively and lose data. In other programs I'd set this up with a shift register in the loop, but since the data is being used in separate simultaneous loops, it's no
t really possible to wire it up that way. I need some sort of memory-space that can be accessed from the various loops.

I guess in sorts, I need to be able to have global variable 'pointers', but of course I was told a couple of years ago at a LabView seminar that pointers was a bad word.

[BJD1613]

You shouldn't have a problem using a LV2 style global veriable with multiple shift registers of data or loop data in your case. Create a while loop with a case structure in side that will only run once. Create a read and a write case. You can write data to each of the shift registers and read data from each of the shift registers. This if used properly will eliminate any race conditions or reading data that isn't correct. Also this vi can be used anywhere you want throughout your app. This is the most standard way of sharing data and a logical way to avoid global variables which have no data dependencies. Hope this helps

[tbob]

There are no pointer types in Labview as far as I know. You might here people say not to use globals. I say if you need it, use it. I think a global is the only way you will be able to solve your problem so create a global of a 3D array containing 200Kb of data. Yes there might be overhead and performance issues. But if you are not concerned with speed, memory use and constant re-writings, the global will work fine. An alternative is to use a functional global, which is a separate vi containing a while loop with an uninitialized shift register, passing data to and from your 3D array control. If you are not familiar with functional globals, let me know and I can explain.

[peter-biomed]

Hmmm....

OK I went looking for LV2 style global variable and I am trying to get a feel for it.

I looked at Global.vi and it is rather simple. For a larger array, I imagine I can just make more 'modes' and have options to set the whole array, read a specific data point, read a column, replace an array subset and such. Is there any special setting to retain the shift register's last value for the last iteration, or is this done so automatically?

[peter-biomed]

Oh and another thing I was thinking about - using the LV2 style global, would it be necessary at all to still use semaphores to ensure avoiding conflicts - or will LabView not let another instance of the same vi run until another iteration is finished.

thanks.

[jbrohan]

peter_biomed wrote in message news:<5065000000050000001EC10100-1079395200000@exchange.ni.com>...
> Oh and another thing I was thinking about - using the LV2 style
> global, would it be necessary at all to still use semaphores to ensure
> avoiding conflicts - or will LabView not let another instance of the
> same vi run until another iteration is finished.
>
> thanks.

Absolutely! LV controls the access to allow only one caller to use a
VI at one time. This means that you cannot have a reader and a writer
accessing a LV2 style global.

If you put the LV2 style global into a VI called CarryArrayxyz.vi then
you get all the convenience of the error cluster for making sure that
the global is updated before it is used. However when you get t
o have
a lot of these globals you need a more radical solution.

I have a toolkit at www.tradersmicro.com (in downloads) called
Configuration File Toolkit which deals extensively with exactly the
issues you are working on. It's two parallel arrays of strings, one
the names and the other the values but it's easy to use. Let me know
what you think!

Yours Sincerely
John

[BJD1613]

There is not a problem with using Globals as long as you use them properly. The problem with using them is race conditions. By using a LV2 style global the data managment is taken care of with only one instance of the vi running at once. The other benefit is the use of additional code such as scaling values or performing manipulation. This all can be abstracted into a LV2style global action engine.

LV2 Style globals and functional globals are the same thing. It is all based around the unitialized shift register which was used in LV2 because there were not global variables then.

Also you could get around using a 3D array by placing a cluster containing a 2d arrays into an array. This might be easier to understand. If you are sticking wi
th the 3D array I like to use the 1D word 2D sentence 3D page 4D book theory. Hope this helps.

[peter-biomed]

Thanks to both of you,

Yes, I think the LV2-style globals will work fine. If I understand correctly, as you mention there will be only be one instance of the vi running at once, then I shouldn't need to use semaphores at all to ensure there is no conflicts between different instances of the LV2 functional global running in different loops (as you would need with standard globals).

Furthermore, are there any 'Vi properties' I need to set to have the shift register retain it's last value in the last instance, or is this automatically handled?

thanks again,

peter

[tbob]

As long as Labview is running, the LV2 style global will automatically retain its last value. Of course the very first time it is run, the value is undefined, so you should write to it before attempting any read.

[rolfk]

tbob wrote:

> As long as Labview is running, the LV2 style global will automatically
> retain its last value. Of course the very first time it is run, the
> value is undefined, so you should write to it before attempting any
> read.

I have one correction to make. The value of an unitialized shift
register on first load is not undefined but rather contains the
datatype's default default value. This would be False for booleans, 0
for numerics and empty arrays or strings.

Rolf Kalbermatter