More details about Surprising LV global variable of type 2

[Brice Chatelan]

I'm using a type 2 global variable because I need a big data array shared by
two parallel VI, so this data array is manipulated in a subVI non reentrant.
One input of this subVI is an enum called method which represents what
action to do on the data of the subVI and this input is directly wired to a
condition structure.
The big data array is contained by an indicator in the front panel of this
subVI because
this big data is an output of the load method so this indicator is wired as
output connector of the subVI because it is needed when loaded.
For other method the big data array is read to extract part of needed data,
so in the subVI diagramm, a readable local variable issued from the big data
arra
y terminal is used . But how big data array is not needed for these
methods, big data array terminal is not rewritten as output in these
condition diagramms because the big data array is theoretically unchanged
and I want to avoid to duplicate my big data array to save time and memory.
The result is surprising because:
After the load method, the big data array output is right.
Then, the input of the second subVI call as a get method is correct.
Readable local variable of the big data array sends right data as input of
the condition associated with this method, in the subVI.
Then, the input of the third subVI call as a get method is wrong. Readable
local variable of the big data array sends wrong data as input of the
condition associated with this method, in the subVI.

So, I suppose I have to wire my big array as output of the condition for
every method call, what lose
a lot of time and memory.

Have you a better idea, please?

[Scott Menjoulet]

Brice Chatelan wrote in message <7qgiua$26k$1@minus.oleane.net>...
>I'm using a type 2 global variable because I need a big data array shared
by
>two parallel VI, so this data array is manipulated in a subVI non
reentrant.
>...
>For other method the big data array is read to extract part of needed data,
>so in the subVI diagramm, a readable local variable issued from the big
data
>array terminal is used . But how big data array is not needed for these
>methods, big data array terminal is not rewritten as output in these
>condition diagramms because the big data array is theoretically unchanged
>and I want to avoid to duplicate my big data array to save time and memory.
>The result is surprising because:
>After the load method, the big data array output is right.
>Then, the input of the second subVI call as a get method is correct.
>Readable local variable of the big data array sends right data as input of
>the condition associated with this method, in the subVI.
>Then, the input of the third subVI call as a get method is wrong. Readable
>local variable of the big data array sends wrong data as input of the
>condition associated with this method, in the subVI.
>
>So, I suppose I have to wire my big array as output of the condition for
>every method call, what lose
>a lot of time and memory.
>
>Have you a better idea, please?
>

Brice,
Are you using a while loop with uninitialized shift-registers in your LV2
style global. This technique is what defines a "LV2 style global" also
called functional globals because you can embed actual functionality into
the VI (for example in your case to extract certain data from an array and
operate on it) as opposed to the read/write only usage of the built in
globals.
From what I can gather, it doesn't sound like you are using the while
loop/shift-register method. You shouldn't need to use a local variable at
all. The data is passed around using the shift-register and it passes
through all of you conditions (load, get, etc.) and no you won't lose time
and memory (or money) doing it this way, certainly not any more than you
would using a local variable. Try it and see if it doesn't fix your
problems and work better than what you are doing now.

If you are using a while loop and shift-registers, then I'm not
understanding clearly what you are doing. Perhaps if you emailed me your VI
(privately of course) to take a look at.

Good Luck!
Scott Menjoulet

[Michael Aivaliotis]

Is there a way to determine the build # of an application built with the
LabVIEW application builder.

What I would like to do is display this on a panel to assist version control
on released apps.
I know, I can put my own number in a text file and read it which is what I'm
doing now but having it automated would be a big support relief.

I know I can get the rev # of a VI using the property node. This would be
enough for my purposes but unfortunately this gets reset when it is built.

Mike



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[Jean-Pierre Drolet]

Mike,

For this purpose, I make a NewBuild.vi that I execute before the build. It
programatically reads revision number(s) and set it as the default value of
a global and save the global in the project. You can include in this VI
whatever you need to do (changes of VI setting, save any info in globals...)
before building the project. It can even call the Application Builder when
it is done.

Hope this helps,

Jean-Pierre
__________________
Jean-Pierre Drolet, Ph. D.
Scientech R&D inc.
Trois-Rivières-Ouest (Québec)
Canada

Michael Aivaliotis a écrit dans le message
<000101befac1$a7118d10$47666b83@bugs>...
>Is there a way to determine the build # of an application built with the
>LabVIEW application builder.
>
>What I would like to do is display
this on a panel to assist version
control
>on released apps.
>I know, I can put my own number in a text file and read it which is what
I'm
>doing now but having it automated would be a big support relief.
>
>I know I can get the rev # of a VI using the property node. This would be
>enough for my purposes but unfortunately this gets reset when it is built.
>
>Mike
>
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.