> that sounds better but with global variables i have the next problem! If
> i acquire the data and store it in the first vi and the second wants to
> read at the same time i would get mixed data. That could be fatal
> results! I have to take care only one vi has access to the global data.
> Can i use semaphores or something else that this will work?
>
This is a good thing to be aware of, but LV makes this much
easier than most languages. Reads and writes of global,
local variables, and all other nodes that access data are
atomic operations. You will never have problems with them
overwriting one another. However, many times what people
are doing is appending to a array. This means that you will
be reading, modifying, and writing for the write operation,
and this definitely isn't atomic. The read operation is
also commonly a read and clear, and it also isn't atomic.
There are two easy ways to deal with this. You can use the
semaphores in the advanced palette to lock around the
compound read and compound writes. An even easier, and
more common solution is to use what is normally referred
to as a LaVIEW 2 style global. The name is historical and
due to the fact that there weren't globals built into LV
before version 3, so people built their own.
What is really built is a functional global, or a
functional interface or accessor function for static
data. It's a subVI that has an operation or mode
selector, one or more data inputs, and one or more
data outputs. On the subVI's diagram is usually a loop
with an uninitialized shift register to store the data
in. Inside the loop, place a case statement with a
mode selector wired to it. In the write frame, place
the write control and wire it out and into the right
shift register. Wire the left shift register into the
case statement, through a tunnel. Wire it through the
write frame, and in the read frame, wire the left data
to the indicator that will return the data. Assuming
that your are clearing the data, wire an empty array or
string to the right shift register.
There are lots of other things that you can do with this,
make other operations or modes, have optional inputs, more
outputs, etc. The reason this works nicely is that each
VI acts as a critical section. As long as it isn't
reentrant, only one call can execute at a time. There
is overhead for the function overhead, but it is quite
small.
Greg McKaskle